Шаблон MVC описывает простой способ построения структуры приложения, целью которого является отделение бизнес-логики от пользовательского интерфейса. В результате, приложение легче масштабируется, тестируется, сопровождается и конечно же реализуется.
Источник Не совсем ясно, что означает этот термин
- терминология
- шаблоны-проектирования
Отслеживать
4,641 1 1 золотой знак 14 14 серебряных знаков 49 49 бронзовых знаков
задан 24 июл 2016 в 16:26
user33274 user33274
5 ответов 5
Сортировка: Сброс на вариант по умолчанию
Бизнес-логика — это логика доменной модели — все, что в вашем приложении происходит в терминах предметной области.
Например, на SO — это все действия с пользователями, вопросами, ответами, плюсы, минусы и т.д.
- Если пользователь не набрал ZZZ репутации — отправить его правку на проверку другими участниками — это бизнес-логика, ей место в модели.
- Перенаправить пользователя на страницу вопроса после его создания — не-бизнес логика, которой место в контроллере.
- Скрыть кнопку «Оставить комментарий» если текущий пользователь не имеет право оставлять комментарии — особенности представление данных (флага из модели) — во view.
MVC позволяет выделить «не-бизнес» логику, связанную с пользовательским интерфейсом:
- вызовы методов модели по определенным действиям пользователя
- отображение/скрытие контролов
- подготовку данных к отправке на клиента.
. и поместить логику представления в отдельный кусок приложения — Controller.
тем самым оставив в модели «чистую» бизнес-логику, не привязанную к интерфейсу пользователя.
Стоит отметить, что ссылка в вопросе ведет на статью, иллюстрированную диаграммой Classic MVC. Реально в Web используется более современный вариант паттерна — MVC Model2 — и его производные. Его отличие — View не взаимодействует с моделью напрямую.
Взаимодействие в современном MVC выглядит вот так:
Отслеживать
ответ дан 25 июл 2016 в 8:09
user177221 user177221
Оборот про «И поместить ее в отдельный кусок приложения — Controller.» совсем не понятен. А еще не понятно как бизнес-логика связана с контролером
25 июл 2016 в 11:11
Я к тому, что процитированный мной кусок, по-логике содержит опечатку. Вместо Controller должно быть Model. Или я чего-то не понимаю?
25 июл 2016 в 11:33
– user177221
25 июл 2016 в 11:37
– user177221
25 июл 2016 в 12:09
– user177221
28 окт 2019 в 14:51
Бизнес-логика — то же самое что и логика предметной/доменной/прикладной области. Допустим, вы программируете софт для приюта животных и для детского приюта.
По бизнес-логике приюта для животных, предположим, котика, которого за неделю не забрали новые хозяева, надо усыпить. А до этого его надо кормить, поить и спать укладывать.
По бизнес-логике детского приюта — ребенка надо кормить, поить и спать укладывать. В него нельзя втыкать шприц со смертельной дозой морфия.
При этом все структуры данных, алгоритмы и т.д. — в двух программах практически одинаковы. Кроме вот этой маленькой детали.
«ЭТОТ один ИФЧИК решил СУДЬБУ КОТЕЙКИ», или, например «начинающий программист УБИЛ младенца ВЕКТОРОМ»
Если вы перепутаете бизнес-логику приюта для животных и детского приюта, и усыпите ребенка, а котенку подарите куклу, вы, надеюсь, попадете в тюрячку, там вам все за ООП расскажут.
Не важно, бизнес это, расчет конфигурации молекул, приют или управление кораблем. Бизнес-логика — это та самая часть, которая в итоге должна работать правильно и надежно, та, результатов которой ждет заказчик (котенок, ребенок)
Если не отделять, допустим интерфейс от бизнес-логики, то вместо нажатия кнопки «отдать ребенка новым родителям» или «усыпить котенка», на двух аккуратных — почти похожих — пультах управления (интерфейсах) вы будете бегать туда-сюда, пытаясь понять, кого утопить, кого усыпить, кого отдать новым родителям и почему ничего не работает.
Вы не отделили интерфейс (панель управления для запуска котят на луну) от бизнес-логики и все запуталось.
Ну, я предупреждал.
Используете вы синглтоны, очереди, базы данных, флэт-файлы, микросервисы — не важно — важно, чтобы бизнес-логика работала правильно.
Под правильно подразумевается корректность результатов в приемлемое время. Все остальное ваших заказчиков не интересует. До тех пор, пока они не являются вашими владельцами.
Именно поэтому вы можете продавать очень плохой — с точки зрения программиста — софт клиентам, но с трудом сможете построить на нем надежную систему. Требования бизнес-логики может быть и выполняются, но поддерживать этот код невозможно
P.S. Маленький исторический экскурс. Бизнес-логикой это называется потому, что в Нормальном Мире, во Внешней Империи, программирование в коммерции и корпорациях развивалось еще с 50х-60х годов: банки, страховые агентства, туроператоры, медицина.
Т.е. тебе платили за то, чтобы ты внедрил требования конкретного бизнеса
Хорошо, что это бизнес-логика, а не партийная логика, как в Северной Корее.
Источник: ru.stackoverflow.com
Бизнес-логика в no-code: что это и как ее построить
Бизнес-логика приложения – это, по сути, описание схем, по которым приложение взаимодействует с пользователем. Когда пользователь оформляет подписку, или заполняет форму заказа, или просто авторизуется – все эти действия обрабатываются «под капотом» приложения в определенном порядке.
3697 просмотров
Какие данные нужно запросить? Соответствуют ли введенные данные заданному формату? Что произойдет после того, как пользователь нажмет кнопку «Подтвердить»? А есть ли вообще у него права доступа к данной операции? На все эти и многие другие вопросы можно ответить, изучив, как построена бизнес-логика конкретного приложения.
Простейший пример: администратор авиакомпании (пользователь) регистрирует пассажира на рейс (вносит информацию в базу данных).
Что делает пользователь:
1.Открывает информацию о выбранном рейсе, переходит к списку уже зарегистрированных пассажиров, нажимает «Зарегистрировать пассажира».
2.Заполняет форму регистрации: вводит номер рейса, выбирает пассажира, указывает место и статус регистрации.
3.Нажимает кнопку «Подтвердить»
4.Видит нового пассажира в общем списке.
Как это выглядит с точки зрения бизнес-логики приложения:
1.Приложение проверяет, авторизован ли пользователь и имеет ли права доступа к выбранной странице, а также операции регистрации.
2.Ждет, пока пользователь заполнит форму.
3.Обрабатывает введенные данные:
a. Проверяет, соответствуют ли введенные данные требованиям приложения (эти требования заранее прописаны программистом): например, в поле «Номер рейса» должно быть целое число.
b. Получает из базы данных информацию: например, о рейсе и связанных с ним регистрациях (чтобы внести изменения), пассажире (чтобы проверить, действительно ли этот пассажир есть в базе данных).
c. Выдает сообщения об ошибках, если поля заполнены неверно.
d. Отправляет информацию в базу данных, отдавая команды на создание в ней новых записей или обновлении существующих.
4.Выводит обновленную информацию на экран.
Общая логика приложения строится из бизнес-процессов – схем, описывающих конкретные операции в системе: создание записи о пассажире, добавление в систему нового рейса, редактирование информации о регистрации.
Когда речь идет о классическом программировании, то для описания всех процессов используются блоки кода. Многие из них пишутся по шаблонам – просто используются в разной последовательности и для работы с разными данными.
Именно благодаря этой «шаблонности» в no-code разработке появилась возможность использовать инструменты визуального программирования – так называемые дизайнеры бизнес-логики. Они помогают выбрать нужные блоки, скомпоновать в нужной последовательности, настроить. И даже создать некоторые блоки автоматически, в зависимости от настроек других компонентов приложения. Итог – готовая бизнес-логика без необходимости проводить многие часы над строками кода.
О том, как настраивать бизнес-логику на платформе Appmaster.io, вы можете узнать из видео о бизнес-процессах.
Источник: vc.ru
