Где разместить бизнес-логику в дизайне MVC?

Я создал простое Java-приложение MVC, которое добавляет записи через формы данных в базу данных.

Мое приложение собирает данные, проверяет и сохраняет их. Это связано с тем, что данные поступают онлайн от разных пользователей. данные в основном числовые по своей природе.

Теперь, когда числовые данные хранятся в базе данных (сервер SQL), я хочу, чтобы мое приложение выполняло вычисления и отображало результаты. Пользователю не интересно, как выполняются вычисления, поэтому они должны быть инкапсулированы. Пользователь должен иметь возможность просматривать только простые вычисленные данные (например, данные столбца A минус данные столбца B, разделенные на данные столбца C). Я знаю, как написать хранимые процедуры для одного и того же, но я хочу трехуровневое приложение.

Я хочу, чтобы данные, которые я помещаю в базу данных в качестве записи, работали над ними, выполняя вычисления. Исходные данные должны оставаться неизменными, в то время как новые данные после вычислений должны храниться в виде новой записи объекта в базе данных.

Где я должен написать код для этого фонового расчета? Как это правила и бизнес-логика, я должен поместить это в новые файлы JavaBeans?

— BriskLabs Пакистан
источник

Возможные дубликаты Staying OO и Testable при работе с базой данных

— gnat

Ответы:

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

Для начала мы должны начать с логики контроллера. Например: при обновлении ваш контроллер должен направлять ваш код в метод / службу, которая доставляет ваши изменения в модель.

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

Концептуальное резюме

Контроллер предназначен для логики приложения. Логика, которая специфична для того, как ваше приложение хочет взаимодействовать с «областью знаний», которой оно принадлежит.
Модель для логики , которая не зависит от применения . Эта логика должна быть действительной во всех возможных применениях «области знаний», которой она принадлежит.
Таким образом, логично поместить все бизнес-правила в модель.

— Е.Л. Юсубов
источник

хороший четкий и краткий ответ ..

— Ханзоло

@Yusubov, не могли бы вы объяснить мне разницу между логикой приложения и бизнес-логикой

— Мохамад,

@Moh, Короче говоря, это модные слова, чтобы помочь описать уровни технологии в приложении. Бизнес-логика - это в основном правила системы в соответствии с функциональными спецификациями. Например, объект A типа B должен иметь атрибуты C и D, но не E. Application Logic - это скорее техническая спецификация, например, использование Java-сервлетов и OJB для сохранения в базе данных Oracle.

— Е.Л. Юсубов

Не могли бы вы уточнить эти слова:

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

[ php-html.net/tutorials/model-view-controller-in-php ]

— revo

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

— Е.Л. Юсубов

Как всегда, это зависит от сложности проекта.

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

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

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

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

У Роберта Мартина (дядя Боб) есть хорошая запись в блоге на эту тему: Чистая Архитектура.

— Хакан Дериал
источник

вопрос был специфичным для MVC. бизнес-логика всегда должна быть в модели. Контроллер - это просто адаптер.

— jgauffin

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

— Хакан Дериал

Из определения Стива Burbeck (Smalltalk команды):

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate

. Это определение адаптера.

— jgauffin

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

— Астаср

Я думаю, что jgauffin понял, что вопрос специфичен для MVC. Если мы согласны рассматривать систему с точки зрения MVC и только с точки зрения MVC, то да, вся бизнес-логика принадлежит «модели», но «модель» может охватывать несколько классов и уровней, включая «служебные классы» и «уровень обслуживания». Другими словами, мы бы не сказали, что сервисный уровень является частью контроллера или представления, поэтому лучше всего подходит модель.

— DavidS

Внедрение бизнес-логики в модель может показаться лучшим вариантом. Контроллер получает вызов от удаленного веб-приложения. Контроллер веб-службы MVC принимает вызов и перенаправляет выполнение методу в BL. Теперь Business Logic может содержаться в «Model», но также может располагаться в какой-то другой папке, например, «Business Logic» . Так что нет строгого правила относительно того, где будет бизнес-логика.

Я использовал веб-сервис, построенный на MVC 3.0, а контейнер бизнес-логики - это MVC MODEL .

— Монти Пайтон
источник

Я согласен. Вы получаете гораздо более гибкое приложение, когда ваша модель представляет собой просто структуру данных, на которую воздействуют другие классы бизнес-логики. В качестве простого примера я думаю, что это большой провал подхода ASP.NET к проверке с использованием атрибутов. Если я аннотирую свойство FirstName человека с помощью атрибута Required, что произойдет, если я создам административное представление, в котором FirstName не требуется? Уровень бизнес-логики должен потреблять модель и определять соответствующие действия для нее.

— xr280xr