Как реализовать единицу работы в MVC: ответственность

Кто несет ответственность


Кто несет ответственность за запуск и завершение Единицы работы в архитектуре MVC?


person SDReyes    schedule 10.02.2010    source источник


Ответы (4)


Контроллер не несет ответственности за это, это нарушает SRP. Контроллер вообще не должен знать о UoW. В сети обычно используется один UoW на запрос к серверу. В этом случае UoW должен быть удален в конце запроса и запущен где-то после начала запроса (в идеале запуск UoW должен быть ленивым). Лучшее место для этого - Global.asax (или ваш класс HttpApplication) с использованием обработчиков Application_EndRequest и Application_BeginRequest.
Этого легко добиться с помощью инфраструктуры IOC (мой любимый - Windsor), см. этот вопрос для получения подробной информации о реализации.

person zihotki    schedule 10.02.2010
comment
@zihotki - что в вашем дизайне добавляет команды в Unit of Work? - person Jeff Sternal; 10.02.2010
comment
@Jeff, все команды / службы / репозитории в запросах разделяют (и принадлежат) одному и тому же UoW. Если для команды / службы / репозитория требуется прямая ссылка на UoW (например, сеанс в NHibernate или DataContext в EF), он должен быть введен IOC. Как именно его следует вводить (установщик или конструктор или прямой вызов IOC), зависит от вашей архитектуры. - person zihotki; 11.02.2010
comment
Лучшее место для этого - Global.asax (или ваш класс HttpApplication) с использованием обработчиков Application_EndRequest и Application_BeginRequest. или вы можете получить новый httpmodule для подключения к этим событиям и предоставить вам объект nHibernateSession для каждого запроса. Я согласен, что явное управление UoW противоречит SRP, но в конечном итоге U находится внутри контекста страницы. Хороший ответ :) +1 - person Mark Dickinson; 11.02.2010
comment
Как насчет модульных тестов? Как бы вы таким образом провели модульное тестирование единицы работы? - person Rushino; 26.01.2011
comment
@Rushino, я протестирую команды и сервисы, и я создам UoW для каждого теста перед тестовым событием и закрою его после тестового события. Но точная реализация будет зависеть от реализации команды или службы. - person zihotki; 01.03.2011

Контроллер. Это получает контекст, поэтому вы можете начать и закончить единицу работы. Например, для сеанса nHibernate для каждого запроса вам потребуется знать, когда запрос был запущен и завершен, поэтому вам нужен контекст, чтобы передать вам запрос.

person Mark Dickinson    schedule 10.02.2010
comment
+1 Спасибо, Марк! В любом случае я подожду дополнительных мнений по поводу:) - person SDReyes; 10.02.2010
comment
Это круто, сложно сказать, каким вы хотите получить ответ, поскольку есть несколько способов взглянуть на единицу работы. У некоторых пользователей есть вся работа для рендеринга страницы, у других есть области транзакций, которые могут обрабатываться другими классами. Я считаю, что даже для более детализированных случаев хорошо, когда контроллер отвечает за ресурсы, которые он может в конечном итоге вернуть (удалить или что-то еще). Может быть, вы могли бы опубликовать больше, и я мог бы попытаться дать лучший ответ. Спасибо :) - person Mark Dickinson; 10.02.2010
comment
Спасибо за ответ, Марк :) Ну, в запросе единицы работы ориентированы. Я думаю, вы правы. Я просто верю, что могло быть что-то, о чем не думали. :) -т.е. У меня не было, хотя в ориентированном на транзакцию UoW: P- Еще раз спасибо - person SDReyes; 10.02.2010
comment
Обновление: см. Заявление Зихотки. - person SDReyes; 11.02.2010

Я верю в слабосвязанную архитектуру. Мой контроллер НИЧЕГО не знает о репозитории, контексте или единице работы. Я создал уровень обслуживания (не уверен, что это правильный термин), который вызывает контроллер. Затем эта служба работает с репозиторием (dll) для сохранения всех данных.

person Spydermary    schedule 01.04.2011

Как сказал zihotki, вы нарушите SRP, если передадите эту ответственность контроллеру. Это шаблон, ориентированный на манипулирование данными, и поэтому контроллер не должен беспокоить ... это может привести к двум нарушениям: одно для SRP и другое для принципа SoC.

Что касается того, кто несет ответственность, это должно быть определено вашей архитектурой. Предложение StartRequest / EndRequest кажется достаточно убедительным.

person JoseMarmolejos    schedule 10.02.2010
comment
Спасибо, Хосе +1. Я тоже согласен с StartRequest / EndRequest. - person SDReyes; 11.02.2010