Контроллеры обрабатывают поток приложений, так куда же девается моя бизнес-логика?

Question

Я начну этот вопрос с признания, что я новичок в MVC. Шаблон проектирования имеет смысл для меня на высоком уровне, но теперь, когда я изучаю ASP.NET MVC, некоторые архитектурные элементы бросают вызов моим предвзятым представлениям. Учиться - это хорошо.

В последнее время я работал с Oxite как инструмент обучения, написанный людьми из компании , которая создала ASP.NET MVC и, следовательно, якобы ссылочное приложение для ASP.NET. MVC.

Но сегодня я увидел сообщение в блоге о Оксите , написанное Робом Конери:

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

Это бросило меня в тупик. Является ли это разделение принципом MVC и, следовательно, ошибкой разработчиков Oxite, или это мнение Роба? Если бизнес-логика принадлежит модели, почему команда Oxite поместила ее в контроллер? Как выполнить действие, которое является бизнес-логикой, если нет в контроллере?

Кроме того, я ошибаюсь, используя Oxite в качестве учебного ориентира, учитывая комментарии, подобные комментариям Роба?

Answer 1

Ваша бизнес-логика входит в ваш бизнес-уровень. Контроллеры используют бизнес-уровень для создания модели ваших представлений для визуализации. Хорошим примером является приложение MVC Storefront, созданное Робом Конери. Oxite в настоящее время получает много плохой прессы, так как он явно не использует фреймворк MVC.

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

Answer 2

Вы можете реализовать свой бизнес-уровень (то есть модель) с вашими сущностями, агрегатами, репозиториями и сервисами. Службы вызывают хранилища, которые извлекают данные из вашего DAL в виде сущностей.

Это можно установить в отдельном отдельном проекте, который является не чем иным, как DLL.

Далее, получите ваше приложение MVC, которое на самом деле является вашим уровнем представления, и пусть оно использует ваш проект бизнес-уровня. контроллеры будут работать с вашими Сервисами и перекачивать данные, сгенерированные этими Сервисами, в ViewData, которые затем добавляются в ваши Представления.

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

Сообщество "пуристов MVC" вызвало бурю негодования по поводу обоснованности использования Oxite в качестве хорошего примера MVC. Суть в том, что бизнес-логика не должна содержаться в контроллерах, что, я уверен, вы увидите в ходе реорганизации Oxite в ближайшие месяцы.