ORM с или без оболочки DAL

Question

Во всех примерах, которые я видел, ORM, как правило, используются непосредственно или за неким хранилищем DAL (предположительно, чтобы их можно было заменить в будущем).

Я не фанат прямыхИспользование ORM будет затруднено, но я также не фанат потери полного отслеживания изменений домена, которое он предоставляет!

В прошлом я писал бы класс отображения данных (Fowler) для каждого объектав моем домене, но из опыта я узнал, что это кодирование CRUD истощает около 1/3 моего времени.

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

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

Кто-нибудь получил реальный совет здесь?Пожалуйста, не чувствуйте себя обязательным, чтобы подсластить ваши ответы !!

Answer 1

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

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

Answer 2

Репозиторий имеет ряд функций:

1. Позволяет для модульного тестирования с фиктивной реализацией
2. Позволяет скрыть полную реализацию ORM от потребителя,и реализовать функции безопасности
3. Он обеспечивает уровень абстракции для бизнес-логики (хотя некоторые люди используют для этого отдельный уровень обслуживания), а
4. Он позволяет при необходимости изменить реализацию ORM..

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