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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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