ASP.NET MVC Трехуровневая - что все остальные делают?

Question

Когда я начинаю работу над новым веб-приложением, я склоняюсь к той же проверенной и проверенной архитектуре ASP.NET MVC, BLL (состоящей из набора сервисов , которые содержат всю бизнес-логику) иDAL (состоящий из набора репозиториев , которые упрощают шаблон работы по чему-то вроде EF / * Linq to SQL *).

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

Мой вопрос: что делают другие?Мне интересно знать, делают ли люди что-то другое в контексте веб-приложения ASP.NET MVC.Например, существуют такие понятия, как CQRS и События домена .Кто-нибудь использует их для решения проблемы с помощью метода, который я описал выше?

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

Answer 1

Я использую CQRS с MVC.Мило.Вы по-прежнему используете шаблон MVC, но в контроллере я использую шаблон команд для записи, и просто чистый NHibernate Linq для чтения ... также немного SolrNet для чтения.: -)

Answer 2

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

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