Как структурировать корпоративное MVC-приложение и куда идет бизнес-логика?

M odel V iew C ontroller звучит так, как будто он обращается к вашим 3 уровням, но это не так. Он действительно упорядочивает составление вашего пользовательского интерфейса. Контроллер находится посередине, и обычно (A) выполняет работу с использованием B объектов полезности, а (B) из B объектов полезности получает объекты M odel для перейти к обзору V . Часть MVC вашей системы (функциональность пользовательского интерфейса) не знает, что происходит на другой стороне бизнес-уровня. БД? Обращения в службу поддержки? Дисковый ввод-вывод? Стрельба из лазеров? Итак, MVC-B -? будет акронимом, описывающим MVC и , как он подключается.

Подумайте о контролере C в центре с линией, ведущей вниз к объектам полезности B . Контроллер обычно получает модель M от объектов полезности B для передачи в вид V , но модель M остается просто данные. Это ключ. Контроллер C теперь в определенном смысле самая умная часть системы, но объекты удобства B по-прежнему остаются самыми мощными.

Итак, объекты M odel являются значительной частью связи между контроллером C и объектами полезности B .Кроме того, каждое представление имеет объект VM ( V iew M odel), который он принимает, это может быть объект M odel, но может быть что-то сконструированное диспетчером C для передачи более сложных наборов информации в V view.

Итак, контроллер ( 1 ) принимает данные от клиента и выполняет действия с бизнес-объектами (при необходимости), возможно, взаимодействуя с использованием объекта модели, а затем ( 2 ) get's M odel объект (ы) из объекта (ов) полезности B , конструирует VM и передает его представлению (возможно нескольким) для рендеринга .

Сначала действительно может показаться, что уровни и уровни повсюду, тем более что переход на MVC - хорошее время, чтобы расширить использование интерфейсов (см. Последние 3 или 4 Твердые принципы ) и модульное тестирование . Вероятно, в вашем проекте будет намного больше файлов , чем в противном случае. Хотя вы быстро понимаете, что на самом деле это отличный способ организовать вещи.

В качестве этой «верхней» части системы, части MVC, нас просто не волнует, как были созданы объекты M odel или что с ними делают объекты полезности B . . Не удивляйтесь, конечно, если ваш объект модели Customer будет очень похож на вашу таблицу db Customers ! Это нормально и часто. Однако у вашего объекта customer M odel и вашего объекта customer B usiness действительно будут разные жизни.Пришло время рассмотреть шаблон репозитория .

Боритесь с искушением быть ленивым и вложите много логики в контролер C . Стремитесь в каждую минуту ставить проблемы там, где они ниже. Контроллер C предназначен только для подключения. Если требуется много кода для создания адекватной виртуальной машины для использования в представлении, это нормально, потому что это работа контроллеров. Слишком часто вы видите бизнес-логику или логику рендеринга в контроллере. Поместите его туда, где оно принадлежит!

Я пытался уравновесить полноту и краткость, но вы задали огромный вопрос!

MVC не является полной архитектурой для ваших нужд, она охватывает только уровень представления. Ваши контроллеры должны взаимодействовать с бизнес-уровнем, чтобы вернуть объекты модели. Бизнес-уровень может взаимодействовать с другими уровнями, такими как доступ к базе данных, веб-службы, файловая система и т. Д.

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

Посмотрите MVC Contrib Project и образец Code Camp, чтобы получить пример этого.

Мне также помогли eCommerce Storefront Роба Конери и Northwind MVC starter kit.

Я обычно помещаю свою бизнес-логику в службы и вызываю их из контроллера, который упорядочивает данные и отправляет их в соответствующую службу.

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

Таким образом, существует полный разрыв между существующей бизнес-логикой и вашим новым кодом на основе MVC.

«Это зависит»:)

Запросы направляются контроллерам, которые обрабатывают их соответствующим образом. Контроллеры - это «клей», который скрепляет все остальное (модели, представления и т. Д.). Поэтому естественно, что «бизнес-логика» будет либо обрабатываться напрямую, либо передаваться контроллеру другому компоненту.

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

В качестве альтернативы вы можете поместить логику во вспомогательные классы / функции или (как уже упоминалось другими) вы можете создать уровень сервисов для бизнес-логики.

Вы можете использовать S # arp Architecture , чтобы правильно структурировать свое приложение с использованием передовых методов. Полный пример приложения доступен по адресу: Кто может мне помочь?

ИМО, этот сценарий больше подходит для чего-то вроде того, что вы бы использовали в WPF. ViewModel View Controller.

Ваш контроллер взаимодействует с бизнес-сервисами, которые выполняют функции с объектами домена. Контроллер преобразует данные, возвращаемые бизнес-сервисами (объединяя несколько, если необходимо), в модели представления («M» в MVC). Затем модель представления передается в представление.

То же самое в обратном порядке, чтобы удалить виртуальные машины из представления и отправить данные обратно в бизнес-службы