За и против Репозиториев DDD
Профессионалы:
- Репозитории скрывают сложные запросы.
- Методы репозитория могут использоваться в качестве границ транзакции.
- ORM можно легко дразнить
Недостатки:
- Платформы ORM уже предлагают набор как интерфейс к постоянным объектам, каково намерение репозиториев. Таким образом, репозитории добавляют дополнительную сложность к системе.
- комбинаторный взрыв при использовании findBy методов. Этих методов можно избежать с объектами Критериев, запросами или объектами в качестве примера. Но не сделать тот никакой репозиторий не необходим, потому что ORM уже поддерживает эти способы найти объекты.
- Так как репозитории являются набором совокупных корней (в смысле DDD), нужно создать и раздать совокупные корни, даже если только дочерний объект изменяется.
Вопросы:
- Какие за и против Вы знаете?
- Вы рекомендовали бы использовать репозитории? (Почему или почему нет?)
2 ответа
Основной смысл репозитория (как и в принципе единой ответственности) заключается в абстрагировании понятия получения объектов, имеющих идентичность. Поскольку я стал более комфортно работать с DDD, я не нашел полезным думать о репозиториях как о репозиториях, которые в основном ориентированы на сохранение данных, а вместо этого как о фабриках, которые инстанцируют объекты и сохраняют свою идентичность.
Когда вы используете ORM, вы должны использовать их API как можно более ограниченным образом, давая себе фасад, возможно, это специфично для домена. Так что независимо от того, что ваш домен все равно будет просто видеть репозиторий. Тот факт, что он имеет ORM на другой стороне, является "деталями реализации".
Репозиторий - это просто слой абстракции, как интерфейс. Вы используете его, когда хотите развязать реализацию персистентности данных (т.е. вашу базу данных).
Я полагаю, что если вы не хотите развязывать вашу DAL, то вам не нужен репозиторий. Но в этом есть много преимуществ, например, тестируемость.
Что касается комбинаторного взрыва методов "Поиск": в .NET вы можете вернуть IQueryable вместо IEnumerable и позволить вызывающему клиенту выполнить на нем Linq-запрос, вместо того, чтобы использовать метод "Поиск". Это обеспечивает гибкость для клиента, но жертвует возможностью предоставить четко определенный, тестируемый интерфейс. По сути, вы обмениваете один набор преимуществ на другой
.