Чего мне не хватает с Respository Pattern?Как вы используете это в реальном мире?

Question

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

Реальный доступ к данным просто не такой. Реальные сценарии доступа к данным могут включать сложные графы объектов и некоторую форму транзакционной оболочки. Например, предположим, я хочу сохранить новый заказ. Это включает запись в таблицы Order, OrderDetails, Invoice, User, History и ItemStock. Все это должно быть совершено, совершено или отменено. Обычно я передаю что-то вроде IDbTransaction и IDbConnection и связываю всю операцию на уровне сервиса.

Где шаблон репозитория подходит к этому? Я что-то упускаю (возможно, Единица работы)? Существуют ли более реалистичные примеры использования репозиториев, чем обычные готовые фрагменты блогов?

Цени любой свет.

Answer 1

Это очень спорный вопрос, но вот моя выгода из моего собственного опыта.

Repository работает в совокупном корне. Например, если OrderItem всегда извлекается как часть Order и не имеет собственного внешнего порядка, то он будет загружен OrderRepository, в противном случае у него будет свой собственный репозиторий.

UnitOfWork является важной концепцией. Допустим, OrderItem является агрегатным корнем и имеет собственный репозиторий. Таким образом, во время создания заказа, OrderManager создаст UnitOfWork работы в блоке using, инициализирует OrderItemRepository и OrderRepository, а затем подтвердит.

UPDATE

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

Answer 2

O / R-Mappers, такие как Hibernate, в основном реализуют шаблон Repository для графов объектов, полностью поддерживая транзакции.Это часто дырявая абстракция, но ее, безусловно, можно заставить работать в сложных реальных сценариях.

Answer 3

Мне нравится думать о хранилище как о другом слое абстракции.Вы должны добавлять уровни абстракции только тогда, когда стоимость их реализации меньше, чем стоимость НЕ выполнения (сопровождение кода, поддержка, улучшения и т. Д.).

Помните, что цель шаблона репозитория состоит в том, чтобы отделить логику, которая извлекает данные (CRUD) и сопоставляет их с моделью сущностей от бизнес-логики, действующей на модели.То, что это часто в конечном итоге делает / выглядит в реальном мире, - это некая форма бизнес-сущностей, которая абстрагирует базовую физическую модель данных.

Что касается вашего вопроса о транзакции, то да, это больше относится к шаблону Единица работы .Поскольку вы упомянули службы, я бы посоветовал вам НЕ передавать ваше соединение вашим различным классам / методам доступа к данным, а вместо этого позволить WCF управлять транзакцией для вас, используя автоматическую регистрацию. Вот выдержка из Книги WCF Ювала Лоуи (настоятельно рекомендуется), которая объясняет, как и почему этот метод управления транзакциями.

Итак, чтобы ответить на ваш вопрос,шаблон репозитория подходит как способ абстрагировать физическую модель данных и отделить CRUD / отображение от бизнес-логики.

Answer 4

Если вам нужен хороший полноценный, широко используемый пример шаблона репозитория, посмотрите на Основные данные Cocoa Я понимаю, что это не в области языков программирования, которую вы заметили. Но обратите внимание, что это НЕ O / R Mapper. Это полная абстракция хранилища объектов. Нет операторов Sql для выполнения, и хотя вы можете выбрать формат используемого внешнего хранилища, вы никогда не будете взаимодействовать с ним напрямую.