Как настроить Единицу Работы - PullRequest
Новая
       22

Как настроить Единицу Работы

2 голосов
/ 01 декабря 2011

Я делаю успехи, но все еще борюсь с Unit of Work в многослойном приложении MVC.Глядя на пример здесь: http://www.asp.net/entity-framework/tutorials/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application UoW оборачивает все репозитории и предоставляет каждому копию одного и того же dbcontext.Тогда контроллер может использовать репозитории с чем-то вроде: 

var courses = unitOfWork.CourseRepository.Get(includeProperties: "Department");

Теперь предположим, что у вас есть сервисный слой, который вместо этого обращается к репозиториям.Вы можете настроить его так, чтобы он зависел от реализации IUnitOfWork, а затем передать реализацию EfUnitOfWork через Unity.Затем, когда Служба завершает какую-либо задачу, она может вызвать unitOfWork.context.SaveChanges ().Но этот подход скрывает реальные зависимости для Сервиса;необходимые репозитории.Это также означает, что тестирование Сервиса требует от вас создания полного UoW.

Так что я подумал, что должен быть другой подход, и мне интересно, является ли одно из следующего или что я упомянул выше (или что-то еще!)правильный подход:

  • Служба принимает те же аргументы репозитория, что и IUnitOfWork.Репозитории связаны с копией dbContext, предоставленной Unity.EfUnitOfWork также связан с той же копией.Служба может затем использовать хранилища, как прежде, и после завершения использовать EfUnitOfWork для фиксации.
  • Служба просто принимает IUnitOfWork, но настраивает необходимые хранилища, передавая им копию переданного в IUnitOfWork.dbcontext

Пожалуйста, помогите!

Джеймс

Ответы [ 2 ]

0 голосов
/ 02 декабря 2011

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

DbContext - это Единица работы. Мне нужно только передать эту единицу работы в реализованные классы EFRepository. Для этого не нужно заходить в Сервисные классы. Так как же класс Service вызывает context.SaveChanges () для обеспечения координации всех связанных изменений, когда у него нет экземпляра DbContext? Ну, он вызывает EFRepository.Save (), который выглядит следующим образом: 

public void Save()
    {
        context.SaveChanges();
    }

При таком подходе классы обслуживания зависят только от хранилищ. Это будет понятно и может быть осмеяно для тестирования. Когда Unity внедряет требуемые объекты Репозитория в Сервис, он может предоставить каждому Репозиторию одинаковый DbContext. Кроме того, только репозитории имеют доступ к DbContext.

Все это может быть очевидным, но это поставило меня в тупик. Или это может быть просто неправильно, в этом случае, пожалуйста, дайте мне знать!

Джеймс

0 голосов
/ 01 декабря 2011

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

Если у вас есть большие блоки обновлений, которые вы хотите делать вместе, вы можете использовать транзакции. Создайте новый TransactionScope и затем вызовите в нем несколько методов уровня обслуживания: 

using(TransactionScope ts = new TransactionScope())
{
  ServiceLayer.DoSomething();
  ServiceLayer.DoSomethingElse();
  ts.Commit();
}
...