ORM - это инструмент, который можно использовать для построения того, что вы называете «хорошо спроектированной системой».Идея заключается в том, что при разработке на нереляционном языке будет несоответствие импеданса между набором реляционных операций, предоставляемым SQL / хранимыми процедурами, и языком, который вы используете для построения остальныхваше приложение.
Для разработчиков, использующих объектно-ориентированный язык (будь то C ++, C # или Java), существует множество соображений при отображении сложной реляционной схемы в богатую модель предметной области.Безусловно, все это отображение можно выполнить в своем собственном коде, но по мере усложнения ваших взаимодействий в этой «ничьей стране» между ОО и реляционными парадигмами становится более полезным механизм ORM и связанные с ним инструменты.
Некоторые соображения при планировании уровня отображения:
- Вам необходимо управлять наследованием одной таблицы или нескольких таблиц?
- Хотите ли вы использовать отложенную загрузку?
- Хотите ли вы синхронизировать классы и таблицы вручную или планируете использовать инструмент для генерации классов для каждой таблицы (например, с помощью
DataSet)?
Другойособенно при работе в команде следует учитывать, что, когда реляционное сопоставление с доменом выполняется вручную, могут существовать большие различия в способе, которым разработчики пишут отображение.Это может привести к несоответствиям, дублированию и пробелам, которые трудно обнаружить.Выбор ORM (особенно хорошо известного / прочно установленного ORM) может оказать огромное (надеюсь, положительное) влияние на решение и уже существующее сообщество, окружающее эту ORM, будет формировать то, как вы представляете себе слой отображения (вы обнаружите, чтонапример, между пользователями Spring.NET и Entity Framework существуют значительные культурные различия.
Является ли ORM хорошей архитектурой?Нет. Есть ли системы, архитектура которых была бы лучше с ORM?определенно.Существуют ли проекты, которые были повреждены из-за ненужного добавления ORM?Я предполагаю, что их много.
Я предлагаю подойти к этому вопросу под другим углом и применить его к конкретному приложению, над которым вы работаете.Есть ли у вас какие-либо болевые точки при использовании SQL и / или хранимых процедур, которые ORM может решить?Видите ли вы какие-либо риски или у вас есть какие-либо опасения по поводу проблем, которые может вызвать внедрение ORM?Только взвесив ответы на эти вопросы, вы сможете определить, подходит ли ORM для какого-либо решения.