Я всегда думал, что бизнес-логика должна быть в контроллере, и что контроллер, поскольку он является «средней» частью, остается статичным и что модель / представление должны передаваться через интерфейсы. Таким образом, вы можете изменить бизнес-логику, не влияя ни на что другое, запрограммировав несколько Моделей (по одной для каждой базы данных / типа хранилища) и десятки представлений (например, для разных платформ).
Теперь я прочитал в этом вопросе, что вы всегда должны помещать бизнес-логику в модель и что контроллер тесно связан с представлением.
Для меня это не имеет смысла и подразумевает, что каждый раз, когда я хочу иметь средства поддержки другой базы данных / типа хранилища, я должен переписывать всю свою модель, включая бизнес-логику.
И если я хочу другое представление, я должен переписать и представление, и контроллер.
Может кто-нибудь объяснить, почему это так или я где-то ошибся?
источник
Вы и большая часть мира программирования, кажется, неправильно понимаете, какова роль частей MVC. Короче, это:
Модель = логика домена
Вид = логика вывода
Контроллер = логика ввода
Это означает, что модель отвечает за всю бизнес-логику: все, что связано с рисованием виджетов на экране, управлением принтером, выводом данных в виде HTML, синтаксическим анализом HTTP-запросов и т. Д., Не относится к модели.
Тем не менее, многие современные так называемые "MVC" фреймворки на самом деле вообще не делают MVC или неправильно маркируют свои части. Довольно часто то, что называется «моделью», является постоянным уровнем модели, в то время как бизнес-логика находится в том, что они называют «контроллером»; Фактический контроллер, как правило, представляет собой просто центральную точку входа с таблицей маршрутизации и небольшим количеством кода в отдельных «контроллерах», чтобы распределять входные данные, которые они получают, в правильные бизнес-процессы. То, что эти фреймворки называют «представлением», на самом деле представляет собой всего понемногу: некоторую логику представления (View), немного обработки и проверки ввода (Controller) и еще немного бизнес-логики (Model). Львиная доля фактического представления обычно называется «шаблонами».
Вы также можете прочитать о многоуровневой архитектуре; где MVC является односторонним (поток Controller -> Model -> View), Multi-Tier - двусторонним (Presentation -> Logic -> Data -> Logic -> Presentation), и довольно много фреймворки, которые претендуют на то, чтобы делать MVC, фактически делают трехуровневую, переназначая презентацию в представление, логику в контроллер и данные в модель.
источник
Чтобы действительно изолировать бизнес-логику и отделить ее от инфраструктуры уровня представления, она должна быть инкапсулирована службами приложений. Архитектура MVC - это способ реализации уровня представления, и он должен оставаться на том же уровне, делегируя всю бизнес-логику этим сервисам приложений. Думайте о моделях представления как об адаптерах между представлением и данными, которые должны отображаться и / или считываться. Контроллер обеспечивает взаимодействие между моделями представлений, представлениями и службами приложений, в которых размещается бизнес-логика.
Сервисы приложений реализуют бизнес-сценарии использования и отделены от уровня представления, будь то MVC или что-то еще. В свою очередь, сервисы приложений могут содержать сценарии транзакций или дизайн, управляемый доменом .
Для хранения служба приложения может ссылаться на хранилище или любую абстракцию механизма персистентности. Различные реализации могут поддерживаться путем абстрагирования доступа к данным в интерфейс. Как правило, эти абстракции являются негерметичными и являются лишь частично переносимыми между реализациями, и часто это тщетная попытка достичь полной переносимости.
ОБНОВИТЬ
Мое предложение основано на гексагональной архитектуре . В гексагональной архитектуре ваша доменная модель (бизнес-логика) лежит в основе. Это ядро инкапсулировано сервисами приложений, которые действуют как фасад . Сервисы приложений - это простые классы, у которых есть методы, соответствующие сценариям использования в вашем домене. Для подробного обсуждения сервисов приложений взгляните на Сервисы в доменно-управляемом дизайне . Пример кода содержит
PurchaseOrderService
службу приложений для домена покупки. (Обратите внимание, что служба приложений не подразумевает использование доменного дизайна.)В гексагональной архитектуре уровень представления MVC является адаптером между моделью вашего домена (бизнес-логикой) и графическим интерфейсом. Модель предметной области не знает о уровне представления, но уровень представления знает о модели предметной области.
Это решение, безусловно, имеет движущиеся части, чем решение, которое помещает бизнес-логику в контроллер, и вы должны взвесить недостатки и преимущества. Причина, по которой я это предлагаю, заключается в том, что я предпочитаю отделить бизнес-логику от уровня представления, чтобы бороться со сложностью. Это становится более важным по мере роста приложения.
источник
Зависит от того, что вы подразумеваете под бизнес-логикой. Любая «логика», которая придает смысл содержанию модели, должна быть в модели. В связанном вопросе ответ с наибольшим количеством голосов, кажется, определяет «бизнес-логику» как что-либо, касающееся данных; это имеет смысл с точки зрения того, что данные бизнеса - это его бизнес!
Однажды я увидел пример создателя Rails (я думаю), который продолжал заниматься именно этим - не вкладывая в модель «бизнес-логику». Его примером был класс контроллера и метод для регистрации приложения и входа в систему - предоставленный пароль в виде открытого текста был зашифрован перед вставкой или запросом к модели (базе данных).
Я не могу придумать лучшего примера чего-то, что не является логикой контроллера и принадлежит непосредственно модели.
Модель могла бы быть интерфейсом к множеству хранилищ данных, облегчая проблемы переносимости. Именно здесь можно найти путаницу по поводу того, является ли интерфейс модели «контроллером».
Вообще говоря, контроллер связывает модель и представление (которые являются основным элементом приложения). В разработке Какао это может быть упрощено до точки, где контроллер обрабатывается через графический интерфейс XCode (объекты контроллера и привязки.)
Раздел GoF «Шаблоны проектирования» на MVC, в общих чертах:
MVC это все о пользовательских интерфейсах. Основное внимание уделяется модели и представлению - определение и отображение данных. Обратите внимание на «протокол подписки / уведомления» - сюда входит ваш контроллер. Вы можете создавать все представления, которые вам нужны; до тех пор, пока они придерживаются протокола, вам никогда не придется прикасаться к модели или контроллеру.
Если вы говорите конкретно о веб-разработке, IMHO, многие популярные веб-фреймворки бывают быстрыми и свободными с термином MVC и определениями его компонентов.
источник
Почему бы вам не ввести уровень обслуживания?
Тогда ваш контроллер станет более компактным и более читаемым, тогда все ваши функции контроллера будут чистыми действиями.
Вы можете разложить бизнес-логику настолько, насколько вам нужно, на уровне сервиса. Повторное использование кода лучше и не влияет на модели и репозитории.
источник