Действительно ли ORM's контрпродуктивен к дизайну OO?

Я также видел системы ORM, которые, как правило, исходят из объектно-ориентированной модели и генерируют базу данных.

Во всяком случае, я бы сказал, что ORM более склонны к созданию хорошего объектно-ориентированного кода, чем к созданию хорошего кода базы данных.

В идеале успешная ORM соединяет два мира, и код вашего приложения будет отличным с точки зрения решения проблем и реализации бизнес-области, а код и модель вашей базы данных будут отличными с точки зрения нормализации, производительности и ETL / отчетности / репликации, что угодно перспектива.

Пример: Многие инструменты OR/M поставляются с генератором объектов в виде таблиц и щелчков мыши.

Да, но есть равное, если не большее количество ORM-решений, которые основываются на ваших объектах и генерируют ваши таблицы базы данных.

Если вы начнете с данных, а затем будете продвигаться вниз, заставляя автоматически генерируемые объекты иметь поведение объектов, то да, вы можете запутаться... Но если вы начинаете с объекта и генерируете базу данных как вторичный слой, в итоге вы получаете нечто более удобное для использования, даже если база данных, возможно, не так оптимизирована, как могла бы быть.

Если вы ищете оправдание, чтобы не использовать ORM, не используйте его. Лично я нахожу, что это экономит мне тысячи строк кода, делая тривиальные вещи, которые ORM делает просто великолепно.

Как и большинство вопросов этого типа, это зависит от вашего использования.

Основные способы использования инструментов ORM:

1. Определение объекта по данным, использование этого объекта во всем коде приложения (BAD BAD BAD)
2. Использование объектов ORM только для доступа к данным, определение ваших собственных объектов с помощью интерпретирующего слоя между (Намного лучше)

Если начинать с нуля, третий метод - это проектирование данных из вашей объектной модели. (Лучше всего, если возможно)

Итак, да, если вы определяете объект с помощью таблиц данных и используете это во всем своем коде, вы не будете использовать OOD и создавать очень плохие проблемы с дизайном и обслуживанием.

Но если вы используете объекты ORM только в качестве инструмента доступа к данным (заменяя ADO), вы можете использовать хорошие OOD и ORM вместе. Конечно, для создания уровня интерпретации требуется больше кода, но он позволяет использовать гораздо более эффективные методы, при этом требуется не намного больше кода, чем старый код ADO.

Если объекты больше не характеризуются поведением, это будет, на мой взгляд, мутят идентичность и ответственность объектов.

Рассматриваемые объекты действительно имеют определенное поведение чтения и записи базы данных. У них просто нет ничего другого.

На самом деле ситуация довольно проста: объектная ориентация не является самоцелью, это средство для достижения цели, но в некоторых случаях она просто не способствует улучшению конечного результата. В качестве примера можно привести множество вариантов использования ORM - это тысячи вариантов CRUD-приложений, которые не нуждаются или не хотят связывать реальное поведение с большей частью обрабатываемых данных.

Приложение в целом приобретает гибкость за счет того, что не кодирует большую часть (если таковая имеется) «поведения» данных в код самого приложения. Вместо этого им часто лучше использовать эти «тупые» данные, которые они просто передают из пользовательского интерфейса в базу данных и обратно в отчеты и тому подобное. С некоторой осторожностью это может обеспечить существенный уровень пользовательской настройки, который практически невозможно сопоставить, когда вы пытаетесь рассматривать данные как реальные объекты с реальным поведением, закодированным в самом приложении.

Конечно, у этого есть и другая сторона: это может существенно усложнить обеспечение целостности данных или то, что данные используются только надлежащим образом - я видел код, который случайно использовал неправильное поле в вычислениях. , поэтому они усредняли количество офисов, а не размеры офисов в квадратных футах. Оба были пользовательскими полями, в которых просто говорилось, что содержимое должно быть числовым. Приложение не могло знать, что одно имеет смысл, а другое - нет.

В системах, где данные отделены от поведения, это абсолютно контрпродуктивно.

Системы Orm склонны анализировать существующие таблицы базы данных для создания глупых "Объектов" на вашем языке. Эти вещи не являются настоящими объектами, потому что они не содержат бизнес-поведения, но поскольку у людей есть эти структуры, они, как правило, хотят их использовать.

Ruby on Rails (Active Record) фактически привязывает ваши данные к классу "Live" - это гораздо лучше.

Я никогда не видел системы, которая бы мне действительно нравилась - ActiveRecord близка к этому, но она делает несколько рубиновых предположений, которые меня не устраивают - самое большое из них - это предоставление публичных setters и getters по умолчанию.

Но если подвести итог - я видел много хороших ОО-программистов, которые писали испорченный код из-за ORM.

Я отвечаю на это с точки зрения C #, поскольку именно там я занимаюсь большей частью своей разработки ....

Я понимаю вашу точку зрения, но я думаю, что с возможность создавать частичные классы, вы по-прежнему можете создавать объекты с любым поведением, которое вам нравится, и по-прежнему получать мощность, которую OR / M привносит в таблицу для извлечения данных.

Я не верю, что ORM контрпродуктивны для объектно-ориентированного проектирования, если только вы не хотите настаивать на том, что настойчивость является неотъемлемой частью поведения.

Я бы отделил настойчивость от делового поведения. Вы, конечно, можете добавить бизнес-поведение к любому объекту, который ORM генерирует для вас.

Судя по тому, что я видел о ORM, они не идут вразрез с принципами объектно-ориентированного программирования - фактически, довольно ортогональными им. (для информации - довольно новичок в технологии ORM, перспектива Java)

Я считаю, что ORM помогают хранить элементы данных класса в постоянном хранилище без необходимости связываться с этим хранилищем и писать этот код самостоятельно. Вы по-прежнему выбираете элементы данных и пишете поведение класса.

Я предполагаю, что вы можете злоупотреблять ORM, чтобы нарушить принципы объектно-ориентированного программирования, но тогда вы можете сделать это с чем угодно. Вы можете использовать инструменты для создания классов скелетных данных из уже существующей таблицы, но вы все равно будете создавать методы и т. Д.