Являются ли ОРМ контрпродуктивными для проектирования ОО?

Ответ 1

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

Почему они не оптимальны с точки зрения ОО? Поскольку объекты, создаваемые ORM, не являются бизнес-объектами, даже с частичными классами и т.п. Поведение модели бизнес-объектов. Сохранение модели объектов ORM. Я не собираюсь тратить десять абзацев, аргументируя это различие. Это что-то Rocky Lhotka довольно хорошо освежилось в его книгах по Business Objects и его CSLA. Независимо от того, любите вы или используете CSLA, я думаю, что его аргументы являются прочными.

Ответ 2

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

У объектов, о которых идет речь, есть чтение и запись базы данных как определенное поведение. У них просто мало чего кроме этого.

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

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

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

Ответ 3

Случай и точка. Многие инструменты OR/M поставляются с генератором объектов "точка-в-базу данных-таблица-и-щелчок".

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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