Где находятся бизнес-правила в MVC

Question

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

Answer 1

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

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

Answer 2

На первый взгляд, я бы сказал, что они принадлежат модели. Запись MVC в Википедии , похоже, согласна: «В MVC модель представляет информацию (данные) приложения и бизнес-правила, используемые для манипулирования данными». В конце концов, под «бизнес-правилами» мы подразумеваем функциональные алгоритмы и логику, которые кодируют область, с которой связано ваше приложение, а не логику, связанную с вводом / выводом. Эта основная бизнес-логика не изменяется или не должна изменяться в зависимости от того, что отображается для пользователя (который является доменом представления), или от ввода пользователя (который в основном принимается контроллером).

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

Answer 3

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

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

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

Answer 4

Цитата из Википедии Статья :

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

Answer 5

Есть ли причина, по которой вы не можете смешивать MVC и Ntier? Наше приложение делает именно это. Наши контроллеры используются для проверки данных и решают, какие вызовы бизнес-уровня сделать.

OurApp.Web - Проект MVC Asp.net
OurApp.Business - Библиотека бизнес-уровня
OurApp.DataAccess - Библиотека уровня данных
OurApp.Entities - в основном все «модели», общие для всех слоев

Answer 6

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

Модель представляет сущности и функциональность домена.

Контроллер - это всего лишь менеджер, который принимает пользовательский ввод и запросы, выполняет действия в / на модели и отображает их в представления на уровне представления. Контроллер также не просто посредник, контроллер представления ИЛИ может воздействовать на модель.

Answer 7

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

В моей архитектуре View -> Model -> Controller -> Business Tier -> Repository, то есть контроллер обращается к грубым данным, представленным бизнес-уровнем / уровнем, передает их в модель, которая массирует их в представительную форму и представление пассивно отображает его. Бизнес-уровень, который можно повторно использовать в любом формате презентации, будет иметь явные правила и доступ к подсистеме с неявными правилами. По замыслу каждый компонент не знает подробностей компонента над ним.

Answer 8

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

Answer 9

Вы, ребята, не правы, бизнес-правила живут в контроллере, а не в модели ...