в MVC / MVP / MVPC где вы размещаете свою бизнес-логику?

Question

в шаблоне проектирования MVC / MVP / MVPC, куда вы помещаете свою бизнес-логику? Нет, я не имею в виду ASP.NET MVC Framework (он же «Tag Soup»).

Некоторые люди говорят, что вы должны поместить его в «Controller» в MVC / MVPC или «Presenter». Но другие считают, что это должно быть частью модели.

Что вы думаете и почему?

Answer 1

Вот как я это вижу:

Контроллер для логики приложения; логика, которая специфична для того, как ваше приложение хочет взаимодействовать с областью знаний, к которой оно относится.

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

Следовательно, почти все бизнес-правила будут в модели.

Я нахожу полезный вопрос, чтобы спросить себя, когда мне нужно решить, куда поместить некоторую логику: «Это всегда правда или только для той части приложения, которую я сейчас кодирую?»

Answer 2

При моей структуре приложений ASP.NET MVC рабочий процесс выглядит следующим образом:

Контроллер -> Услуги -> Хранилища

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

Answer 3

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

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

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

При таком расположении услуга может использоваться сама по себе, даже без пары контроллер / просмотр. Это может быть локальный или удаленный объект, упакованный и развернутый любым удобным для вас способом, с которым работает контроллер.

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

Я думаю, что этот дизайн более ориентирован на обслуживание.

Answer 4

Поместите свою бизнес-логику в домен и держите свой домен отдельно. Я предпочел Presenter -> Command (команда сообщения использовать NServiceBus) -> домен (с ограниченным контекстом BC) -> EventStore -> обработчик событий -> репозиторий (модель чтения). Если логика не подходит для домена, используйте сервисный уровень.

Пожалуйста, прочитайте статью Мартина Фаулера, Эрика Эвана, Грега Янга и Уди Дахана. Они имеют очень четкую картину.

Вот статья, написанная Марком Нейхофом: http://elegantcode.com/2009/11/11/cqrs-la-greg-young/

Answer 5

Во что бы то ни стало, поместите это в модель!

Конечно, некоторые взаимодействия с пользователем должны быть видны, которые будут связаны с вашим приложением и бизнес-логикой, но избегайте этого, насколько это возможно. По иронии судьбы, следуя принципу «делать как можно меньше», поскольку пользователь «работает» в вашем графическом интерфейсе, и столько же во время «отправки» или запросов действий обеспечивает лучший опыт и удобство использования, а не наоборот , По крайней мере, для бизнес-приложений.

Answer 6

Вы можете поместить его в двух местах. Контроллер и на уровне презентации. Имея некоторую логику на уровне презентации, вы можете ограничить количество запросов обратно в архитектуру, которая добавляет нагрузку на систему. Да, вам нужно дважды написать код, но иногда это то, что вам нужно для отзывчивого взаимодействия с пользователем.

Мне нравится то, что здесь было сказано (http://www.martinhunter.co.nz/articles/MVPC.pdf)

"С MVPC компонент презентатора модели MVP разделен на два компоненты: презентатор (логика управления представлением) и контроллер (логика управления абстрактным назначением). "