2

В настоящее время я работаю над веб-приложение, которое состоит из 6 слоев:ASP.NET MVC - Использование UnitOfWork

  • Web (ссылки на ViewModels и контроллеры)
  • ViewModels
  • Контроллеры
  • Услуги (ссылки на данные и лицо)
  • данных (ссылка на лицо)
  • Сущности

Я пытаюсь реализовать шаблон «UnitOfWork», и поэтому у меня есть класс, который вводится DI для этого задания, что позволяет делать .commit() в actionresult в контроллере, когда я Выполняется с базой данных.

Теперь мой вопрос ... Где должен быть размещен этот класс UnitOfWork? Это на данный момент в моем слое данных, но для этого требуется, чтобы уровень контроллера ссылался на уровень данных и уровень сервиса, что по-моему нечетно ... Должен ли я переместить класс/интерфейс UnitOfWork на уровень сервиса и использовать DI?

ответ

5

Если вы не используете шаблон хранилища в своем Данные слой, который тратит ваше время.

Точкой в ​​UOW является для обработки изменений на несколько Repository случаев это делается следующим образом:

  1. Единица работы вытекает из фактического основного контекста (DataContext - L2SQL, ObjectContext/EF)
  2. Хранилища берут единицу работы в своем доме.

Группа работы сделать две вещи:

  1. Have A Commit() метод
  2. Expose основной объект/субъект установлен в хранилище.

Это немного сложно получить все настройки, но как только вы это сделаете, поток должен быть таким:

  1. Контроллер получить-х DI'ed услуги и единицы работы (как через интерфейсы)
  2. Метод вызова контроллера в сервисе («CustomerServices.AddOrder() ")
  3. служба вызывает метод на Repository
  4. Repository называет„Добавить“метод на„Заказ“объекта/субъекта набор
  5. Контроллер совершает Единица работы

По существу, каждый слой принимает экземпляр «следующего слоя» в их конструкторе. Все, что должно быть DI'ed и управляться интерфейсом. UoW не полагается ни на что, но репозиторий полагается на него для сохранения на «внутреннюю память» (ORM) то UoW «Commit» выведет изменения в базу данных (в основном обертывает метод SaveChanges).

Как Единица измерения - это проблема инфраструктуры/персистентности/базы данных/транзакций, она должна войти в ваш уровень данных. Контроллеры должны ссылаться только на них.

HTH.

+0

Точно! - вот как это работает ... Но мне просто интересно, ГДЕ разместить IUnitOfWork (какой слой?) – ebb

+0

@ebb - уровень данных. это проблема инфраструктуры/данных. – RPM1984

+0

@ RPM1984 - Но это сделает мой слой контроллера ссылкой как на уровне сервиса, так и на уровне данных? – ebb

0

Я внедрил свой класс IUnitOfWork, который должен быть передан непосредственно в мои контроллеры MVC (вводится через замок Виндзор). Затем я передаю его контроллеру любым объектам службы, которые он создает.

0

IUnitOfWork должен быть интерфейсом для уровня данных. Когда запрос поступит в Контроллер, тогда вызовите методы обслуживания, если вам требуется CRUD, следует вызвать UnitOfWork. Вы можете использовать Session Per Request по вызову UnitOfWork в Global.asax Request_Start и совершать транзакции в Request_End.

+1

Но весь смысл UnitOfWork заключается в том, чтобы сделать его независимым от уровня сервиса. Сервис должен знать только о слое данных. Таким образом, service = add/delete/update, ActionResult в контроллере = .commit(), чтобы сразу очистить все операции, чтобы уменьшить количество поездок в базу данных. – ebb

+0

Ваш сервисный уровень не зависит от UnitOfWork, но должен зависеть от уровня интерфейса, который содержит IUnitOfWork –

Смежные вопросы