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

Question

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

Answer 1

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

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

Answer 2

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

Однако, чтобы создать модель представления, вам, как правило, нужно перейти к моделям вашего домена, где живет вся ваша бизнес-логика. На этом этапе 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 - > Модель - > Контроллер - > Бизнес-уровень - > Репозиторий правил, то есть контроллер обращается к грубым данным, представленным бизнес-уровнем / уровнем, передает их в модель, которая массирует их в презентабельную форму, и представление пассивно отображает их. Бизнес-уровень, который можно повторно использовать в любом формате презентации, будет иметь явные правила и доступ к подсистеме с неявными правилами. По своему дизайну каждый компонент не знает подробностей компонента над ним.

Answer 8

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

Answer 9

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