Бизнес-логика, что это такое?

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


Источник

Не совсем ясно, что означает этот термин 
    

Ответы

Ответ 1

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

Например, на SO - это все действия с пользователями, вопросами, ответами, плюсы
минусы и т.д. 

Пример: 


Если пользователь не набрал ZZZ репутации - отправить его правку на проверку другими участниками - это бизнес-логика, ей место в модели.
Перенаправить пользователя на страницу вопроса после его создания - не-бизнес логика, которой место в контроллере.
Скрыть кнопку "Оставить комментарий" если текущий пользователь не имеет право оставлять комментарии - особенности представление данных (флага из модели) - во view.


MVC позволяет выделить "не-бизнес" логику, связанную с пользовательским интерфейсом:


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


... и поместить логику представления в отдельный кусок приложения - Controller.

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



Стоит отметить, что ссылка в вопросе ведет на статью, иллюстрированную диаграммо
Classic MVC. Реально в Web используется более современный вариант паттерна - MVC Model2 - и его производные. Его отличие - View не взаимодействует с моделью напрямую.

Взаимодействие в современном MVC выглядит вот так:


Ответ 2

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

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

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

При этом все структуры данных, алгоритмы и т.д. - в двух программах практически одинаковы. Кроме вот этой маленькой детали. 

"ЭТОТ один ИФЧИК решил СУДЬБУ КОТЕЙКИ", или, например "начинающий программист УБИЛ младенца ВЕКТОРОМ"

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

Не важно, бизнес это, расчет конфигурации молекул, приют или управление кораблем
Бизнес-логика - это та самая часть, которая в итоге должна работать правильно и надежно, та, результатов которой ждет заказчик (котенок, ребенок)

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

Вы не отделили интерфейс (панель управления для запуска котят на луну) от бизнес-логики и все запуталось. 

Ну, я предупреждал.

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

Под правильно подразумевается корректность результатов в приемлемое время. Все остальное ваших заказчиков не интересует. До тех пор, пока они не являются вашими владельцами.

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

P.S. Маленький исторический экскурс.
Бизнес-логикой это называется потому, что в Нормальном Мире, во Внешней Империи
программирование в коммерции и корпорациях развивалось еще с 50х-60х годов: банки, страховые агентства, туроператоры, медицина. 

Т.е. тебе платили за то, чтобы ты внедрил требования конкретного бизнеса 

Хорошо, что это бизнес-логика, а не партийная логика, как в Северной Корее.


Ответ 3

Это логика, которая рассматривает задачу в терминах реального мира, конкретного бизнеса
То есть это может быть прогрессивная шкала налогообложения, (именно описание того, ка
она формируется и что из этого получается), принципы формирования счетов, распределение коэффициентов зарплат сотрудников, но не порядок подключения файлов в движке, не подстройка балансировки нагрузки: это наши проблемы, а не бизнеса.


Ответ 4

Читайте бизнес-логика, как просто логика. Всё. 

А отделение её от UI - то и означает: что в представлении не должно всяких обращени
к БД, выборок из неё, вспомогательных функций на N-строк, например хитроумная сортировка, фильтрация, структурирование данных; шифрование данных; проверка на правильность логина/пароля и прочих каких-либо сверх манипуляций с данными. 

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



The end.


Ответ 5

К примеру у вас приложение справочник телефонных номеров. 
В зависимости от кода страны вы будете использовать то или иной формат отображения
В базе данных вы будете хранить без форматирования (для улучшения индексации и поиска)
Так вот, вы можете вытащить номера прямо из базы и форматировать отображение телефонног
номера в View. Но лучше всего создать слой (бизнес слой) который будет заниматься вытаскиванием из базы и форматированием (что и называется бизнес логикой), и передать в View. Нужно чётко понимать что View это представление, он показывает то что мы дадим, а не по своему.