Являются ли ORM контрпродуктивными для дизайна ОО?

Question

В OOD дизайн объекта, как говорят, характеризуется его индивидуальностью и поведением.

Используя ORM в прошлом, основная цель, на мой взгляд, вращается вокруг способности хранить / извлекать данные. То есть объекты ORM проектируются не по поведению, а по данным (то есть таблицам базы данных). Дело и точка зрения: многие инструменты ORM поставляются с генератором точка-таблица-таблица-и-щелчок-объект.

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

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

Итак, мой вопрос, вы думаете, что ORM являются контрпродуктивными для дизайна ОО? Возможно, основной вопрос заключается в том, являются ли они контрпродуктивными для разработки приложений.

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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

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

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

Answer 9

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

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