Структурирование уровня доступа к данным

#orm #architecture #repository-pattern #data-access-layer

#orm #архитектура #репозиторий-шаблон #уровень доступа к данным

Вопрос:

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

Ответ №1:

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

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

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