в шаблоне проектирования MVC/MVP/MVPC, где вы помещаете свою бизнес-логику? Нет, я не имею в виду ASP.NET MVC Framework (он же "Tag Soup" ).
Некоторые говорят, что вы должны поместить его в "Контроллер" в MVC/MVPC или "Presenter". Но другие считают, что это должно быть частью Модели.
Что вы думаете и почему?
Вот как я это вижу:
Контроллер предназначен для прикладной логики; логика, которая специфична для того, как ваше приложение хочет взаимодействовать с областью знаний, к которой она относится.
Модель предназначена для логики, которая не зависит от приложения. то есть логики, которая действительна во всех возможных приложениях области знания, к которой она относится.
Следовательно, почти все бизнес-правила будут в модели.
Я нахожу полезный вопрос, чтобы спросить себя, когда мне нужно решить, где поставить какую-то логику, "всегда ли это так, или просто для части приложения, которое я сейчас кодирую?"
У меня есть структура приложения ASP.NET MVC, рабочий процесс выглядит следующим образом:
Контроллер → Услуги → Репозитории
Уровень сервисов выше, где происходит вся бизнес-логика. Если вы разместите свою бизнес-логику на своем уровне контроллера, вы потеряете возможность повторно использовать эту бизнес-логику в других контроллерах.
Я не верю, что он принадлежит контроллеру, потому что когда он встроен туда, он не может выйти.
Я думаю, что MVC должен иметь еще один слой, который вводится между ними: сервисный уровень, который отображается в случае использования. Он содержит бизнес-логику, знает об единицах работы и транзакциях и касается объектов модели и персистентности для выполнения своих задач.
Контроллер имеет ссылку на сервис, который должен выполнить его прецедент. Он заботится о том, чтобы развязать запросы на объекты, с которыми может работать служба, вызывает службу и отправляет ответ для отправки обратно в представление.
При таком расположении услуга может использоваться сама по себе, даже без пары контроллеров/представлений. Это может быть локальный или удаленный объект, упакованный и развернутый любым способом, с которым имеет дело контроллер.
Теперь контроллер теперь более тесно связан с представлением. В конце концов, контроллер, который вы будете использовать для рабочего стола, скорее всего, будет отличаться от того, который используется для веб-приложения.
Я думаю, что этот дизайн более ориентирован на обслуживание.
Поместите свою бизнес-логику в домен и сохраните свой домен separte. Я предпочитаю Presenter → Command (Message command use NServiceBus) → Домен (с ограниченным контуром BC) → EventStore → Обработчик событий → Репозиторий (модель чтения). Если логика не подходит для домена, то используйте сервисный уровень.
Прочтите статью от Мартина Фаулера, Эрика Эвана, Грега Янга и Уди Дахана. Они определяют очень четкую картину.
Вот статья, написанная Марк Нийхоф: http://elegantcode.com/2009/11/11/cqrs-la-greg-young/
Ради всего этого, поставьте его в модель!!!!!
Конечно, некоторые из пользовательских взаимодействий должны быть в представлении, которое будет связано с вашим приложением и бизнес-логикой, но избегайте этого как можно больше. По иронии судьбы, следуя принципу как можно меньше, так как пользователь "работает" в вашем графическом интерфейсе и так много во время "отправки" или запросов действий, обеспечивает лучший пользовательский интерфейс и удобство использования, а не наоборот. По крайней мере, для бизнес-приложений.
Вы можете поместить его в два места. Контроллер и уровень представления. Имея некоторую логику на уровне презентации, вы можете ограничить количество запросов обратно в архитектуру, которая добавляет нагрузку на систему. Да, вам нужно дважды вводить код, но иногда это то, что вам нужно для быстрого реагирования на пользователя.
Мне нравится то, что было сказано здесь (http://www.martinhunter.co.nz/articles/MVPC.pdf)
"С MVPC компонент-презентатор модели MVP разбивается на два компоненты: презентатор (логика управления просмотром) и контроллер (логика управления абстрактным назначением).