Могу ли я определить один класс хранилища для всех классов сущностей, которые у меня есть - PullRequest
2 голосов
/ 28 января 2012

Я работаю над веб-приложением MVC 3, которое содержит около 15 классов моделей сущностей, представляющих 15 таблиц БД. В настоящее время я выполняю всю бизнес-логику в одном классе репозитория моделей, который вызывается из всех имеющихся у меня классов контроллеров. Я делаю всю свою работу в одном хранилище, чтобы: -

  1. избегать частичных обновлений.
  2. Обернуть все изменения (вставить, обновить, удалить) в одну транзакцию БД.
  3. чтобы избежать определения класса репозитория для каждого объекта модели и создания класса UnitOFWork для координации между всеми репозиториями, что, как я считаю, усложнит код и добавит дополнительные усилия.

поэтому мой подход к созданию одного класса репозитория будет страдать от таких проблем, как производительность, безопасность и т. Д., Или других проблем, о которых мне следует знать.

Ответы [ 2 ]

2 голосов
/ 28 января 2012

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

Существует книга под названием Domain Driven Design.Одна из рекомендаций - попробовать использовать репозитории «Aggregate Root».Здесь вы объединяете свои сущности в группы в соответствии с их отношениями, а затем создаете один репозиторий для каждой группы.Основная сущность в хранилище упоминается как «совокупный корень» группы и имеет другие сущности, «свисающие» с нее.

Например, скажем, у вас есть сущность Order, которая имеет коллекцию сущностей LineItem.В действительности вы можете получить доступ только к позициям через заказ, поэтому вам не нужен отдельный LineItemRepository.Вы можете запросить заказ, и лениво загружать позиции.В таком случае Заказ может иметь свойство навигации для сущности CustomerAccount, которая имеет коллекцию сущностей PaymentProfile.Опять же, тот же шаблон - вы просто создаете репо для учетной записи клиента и никогда не запрашиваете PaymentProfile напрямую.Запросите его через CustomerAccount.

Также я знаю по одному из ваших предыдущих вопросов, что вы используете EF.EF управляет транзакциями для вас.Каждый раз, когда вы вызываете SaveChanges, EF запускает его в транзакции.Таким образом, # 2 на самом деле не является хорошей причиной иметь 1 гигантский репозиторий.

Обновление

Что касается UnitOfWork, с хорошим предварительным дизайном, вы можете управлять UoW через репозиториидовольно легкоКаждый из наших репозиториев имеет объект UnitOfWork (который в основном оборачивает EF DbContext).Ни один из нашего кода не создает объект напрямую.Вместо этого мы используем наш контейнер Inpension Inversion of Control (Microsoft Unity) для автоматического создания UoW каждый раз, когда репозиторий создается контроллером (опять же, с использованием внедрения зависимостей).

Конфигурируя время жизни зависимости как один экземпляр для каждого запроса, мы можем быть уверены, что по крайней мере в нашем проекте MVC каждый репозиторий получит один и тот же экземпляр UoW (и, следовательно, все репозитории имеют один и тот же экземпляр DbContext).

<register type="IUnitOfWork" mapTo="CustomDbContext">
    <lifetime type="singleton-per-http-context" />
</register>
0 голосов
/ 28 января 2012

Почему бы не реализовать универсальный репозиторий.Прочитайте эту статью, надеюсь, что она может помочь

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...