Куди подіти бізнес-логіку в дизайні MVC?

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

Мій додаток збирає дані, також перевіряє їх і зберігає. Це тому, що дані отримують в Інтернеті від різних користувачів. дані мають в основному числовий характер.

Тепер на числових даних, що зберігаються в базі даних (SQL-сервер), я хочу, щоб моя програма виконувала обчислення та відображала результати. Користувача не цікавить, як проводяться обчислення, тому вони повинні бути інкапсульовані. Користувач повинен мати можливість переглядати лише прості обчислені дані (наприклад, Дані стовпця мінус B Дані стовпця, розділені на дані стовпців C). Я знаю, як записати збережені процедури для тих же, але мені потрібно трирівневу програму.

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

Де мені написати код для цього фонового розрахунку? Оскільки це правила та логіка бізнесу, чи потрібно це вміщувати у нові файли JavaBeans?

— BriskLabs Пакистан
джерело

можливий дублікат Staying OO та Testable під час роботи з базою даних

— gnat

Відповіді:

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

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

У моделі ми можемо легко створити допоміжні / службові класи, де правила чи розрахунки прикладних програм можуть бути перевірені.

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

Контролер призначений для логіки програми. Логіка, яка специфічна для того, як ваша програма хоче взаємодіяти з "областю знань", якій вона належить.
Модель для логіки , яка не залежить від застосування . Ця логіка повинна бути дійсною у всіх можливих сферах застосування «області знань», до якої вона належить.
Таким чином, логічно розмістити всі правила бізнесу у моделі.

— Е. Л. Юсубов
джерело

приємна чітка і лаконічна відповідь ..

— hanzolo

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

— Mohamad

@Moh, Коротше кажучи, це слова, які допоможуть описати рівні технології в додатку. Бізнес-логіка - це в основному правила системи відповідно до функціональних умов. Наприклад, Об'єкт A типу B повинен мати атрибути C і D, але не E. Логіка додатків - це більше технічна специфікація, як, наприклад, використання сервлетів 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

Якщо ви вкладете всю логіку в модель, ви закінчитеся тисячами рядків незбагненного безладу. Був там. Не гріх мати утилітні класи та рівень обслуговування.

— asthasr

Я думаю, що до того, до чого потрапляв jgauffin, є те, що питання специфічне для MVC. Якщо ми погоджуємось розглядати систему з точки зору MVC і лише з точки зору MVC, то так, вся логіка бізнесу належить до "моделі", але "модель" може охоплювати кілька класів і шарів, включаючи "класи класів" та "сервісний рівень". Інакше кажучи, ми не говорили б, що сервісний рівень є частиною контролера або перегляду, тому найкраще підходить модель.

— DavidS

Введення ділової логіки всередині моделі може здатися найкращим способом. Контролер отримує дзвінок із віддаленого веб-додатка. Контролер у веб-службі MVC приймає виклик та перенаправляє виконання до методу на BL. Тепер Business Logic може міститися у "Моделі", але також може бути розміщена в іншій папці, скажімо, "Business Logic" . Тож немає чіткого і швидкого правила щодо того, де знаходиться бізнес-логіка.

Я використовував веб-сервіс, побудований на MVC 3.0, і контейнером ділової логіки є MVC MODEL .

— MontyPython
джерело

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

— xr280xr