Бізнес - логіка, що це таке stack overflow російською
Бізнес-логіка - це логіка доменної моделі - все, що у вашому додатку відбувається в термінах предметної області.
Наприклад, на SO - це всі дії з користувачами, питаннями, відповідями, плюси, мінуси і т.д.
Якщо користувач не набрав ZZZ репутації - відправити його правку на перевірку іншими учасниками - це бізнес-логіка, їй місце в моделі.
Перенаправити користувача на сторінку питання після його створення - Ні-бізнес логіка, якій місце в контролері.
MVC дозволяє виділити «не-бізнес" логіку, пов'язану з призначеним для користувача інтерфейсом:
- виклики методів моделі по певних дій користувача
- відображення / приховування контролів
- підготовку даних до відправки на клієнта.
і помістити логіку уявлення в окремий шматок додатки - Controller.
тим самим залишивши в моделі "чисту" бізнес-логіку, не прив'язану до інтерфейсу користувача.
Взаємодія в сучасному MVC виглядає ось так:
Бізнес-логіка - те ж саме що і логіка предметної / доменної / прикладної області. Припустимо, ви програмуєте софт для притулку тварин і для дитячого притулку.
За бізнес-логікою притулку для тварин, припустимо, котика, якого за тиждень не забрали нові господарі, треба приспати. А до цього його треба годувати, поїти і спати укладати.
За бізнес-логікою дитячого притулку - дитину треба годувати, поїти і спати укладати. У нього не можна встромляти шприц зі смертельною дозою морфію.
При цьому всі структури даних, алгоритми і т.д. - в двох програмах практично однакові. Крім ось цієї маленької деталі.
"ЦЕЙ один ІФЧІК вирішив ДОЛЮ Котейко", або, наприклад "програміст УБИЛ немовляти вектор"
Якщо ви переплутаєте бізнес-логіку притулку для тварин і дитячого притулку, і приспите дитини, а кошеняті подаруйте ляльку, ви, сподіваюся, потрапите в тюрячку, там вам все за ООП розкажуть.
Не важливо, бізнес це, розрахунок конфігурації молекул, притулок або управління кораблем. Бізнес-логіка - це та сама частина, яка в підсумку повинна працювати правильно і надійно, та, результатів якої чекає замовник (кошеня, дитина)
Якщо не відокремлювати, припустимо інтерфейс від бізнес-логіки, то замість натискання кнопки "віддати дитину новим батькам" або "приспати кошеня", на двох акуратних - майже схожих - пультах управління (інтерфейси) ви будете бігати туди-сюди, намагаючись зрозуміти, кого втопити, кого приспати, кого віддати новим батькам і чому нічого не працює.
Ви не відокремили інтерфейс (панель управління для запуску кошенят на місяць) від бізнес-логіки і все заплуталося.
Ну, я попереджав.
Чи використовуєте ви Сінглтон, черги, бази даних, флет-файли, мікросервіси - не важливо - важливо, щоб бізнес-логіка працювала правильно.
Під правильно мається на увазі коректність результатів в прийнятний час. Все інше ваших замовників не цікавить. До тих пір, поки вони не є вашими власниками.
Саме тому ви можете продавати дуже поганий - з точки зору програміста - софт клієнтам, але з працею зможете побудувати на ньому надійну систему. Вимоги бізнес-логіки може бути і виконуються, але підтримувати цей код неможливо
P.S. Маленький історичний екскурс. Бізнес-логікою це називається тому, що в Нормальному Світі, в Зовнішній Імперії, програмування в комерції та корпораціях розвивалося ще з 50х-60х років: банки, страхові агентства, туроператори, медицина.
Тобто тобі платили за те, щоб ти впровадив вимоги конкретного бізнесу
Добре, що це бізнес-логіка, а не партійна логіка, як в Північній Кореї.
Читайте бізнес-логіка. як просто логіка. Усе.
А відділення її від UI - то і означає: що в поданні не повинно всяких звернень до БД, вибірок з неї, допоміжних функцій на N-рядків, наприклад хитромудра сортування, фільтрація, структурування даних; шифрування даних; перевірка на правильність логіна / пароля і інших будь-яких понад маніпуляцій з даними.
У поданні має бути відображення кінцевого результату, який прийде у відповідь на запит до керуючого класу, а все маніпулювання (як описано вище) даними (логіка) - має відбуватися в іншому місці.