Шаблон MVC описывает простой способ построения структуры приложения, целью которого является отделение бизнес-логики от пользовательского интерфейса. В результате, приложение легче масштабируется, тестируется, сопровождается и конечно же реализуется.
Источник Не совсем ясно, что означает этот термин
- терминология
- шаблоны-проектирования
Отслеживать
4,641 1 1 золотой знак 14 14 серебряных знаков 49 49 бронзовых знаков
задан 24 июл 2016 в 16:26
user33274 user33274
5 ответов 5
Сортировка: Сброс на вариант по умолчанию
Бизнес-логика — это логика доменной модели — все, что в вашем приложении происходит в терминах предметной области.
Например, на SO — это все действия с пользователями, вопросами, ответами, плюсы, минусы и т.д.
- Если пользователь не набрал ZZZ репутации — отправить его правку на проверку другими участниками — это бизнес-логика, ей место в модели.
- Перенаправить пользователя на страницу вопроса после его создания — не-бизнес логика, которой место в контроллере.
- Скрыть кнопку «Оставить комментарий» если текущий пользователь не имеет право оставлять комментарии — особенности представление данных (флага из модели) — во view.
MVC позволяет выделить «не-бизнес» логику, связанную с пользовательским интерфейсом:
Что такое логика — [Логика #2]
- вызовы методов модели по определенным действиям пользователя
- отображение/скрытие контролов
- подготовку данных к отправке на клиента.
. и поместить логику представления в отдельный кусок приложения — 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
Developer’s Notes
Здравствуйте, уважаемые читатели моего блога. В этой статье постараюсь выразить субъективною точку зрения про принципы работы логики ПО (программного обеспечения) на объектно-ориентированных языках высокого уровня. Буду благодарен за комментарии к статье и Ваше виденье этого процесса.
Также постараюсь объяснить разницу между администраторами, которые помогают пользователю настроить что-то в системе, и разработчиками ПО. Употребление терминологии по разработке ПО необходимо для того, чтобы соответствовать заголовку статьи, но использовать ее постараюсь по минимуму . Мне очень нравятся две цитаты с того времени, как я стал заниматься программированием: “ Всё гениальное просто ” и “ Если вы не можете объяснить что-то шестилетнему ребенку, значит, вы сами этого не понимаете ” ( А.Эйнштейн). Поэтому буду стараться, чтобы все было предельно просто и понятно.
Пожалуй, сразу отвечу на вопрос, чем логика программистов отличается от логики обычных пользователей, — людей, которые сидят по другую сторону монитора и пользуются творениями рук программистов. Ответ очевиден: ничем. Она только немного специфическая в зависимости от того, насколько человек увлечен разработкой ПО. О логике программистов ходят легенды.
Мне очень понравилась история о б аналитическом мышлении программистов. » На работу к нам приехал программер из фирмы, которая пишет для нас софт. Хороший парень, с чувством юмора. Мы собрались идти на обед.
Не помню как, но слово за слово и я выдвигаю ему такую фразу: «А вот американские ученые провели в свое время такой эксперимент: поделили подопытных крыс на две группы и стали их по-разному кормить. Первую группу ни в чем не ограничивали, а вторую кормили пайком ровно в два раза меньшим, чем первую. В итоге вторая группа крыс прожила в два раза дольше. Вот. Программист посмотрел на меня и сказал без тени улыбки: Да, но сожрали-то они в конечном итоге столько же. ” Вероятно, туман завесы над логикой этой категории специалистов начинает развеиваться перед Вами.
Постараюсь объяснить на простых примерах , что такое программирование, т.к. в случае использования сложной терминологии при обозначении этого понятия простые читатели будут недовольны. Да и надо же разработчику тренировать умение общаться по-человечески, не употребляя технических терминов. Итак, представьте, что Вы проснулись утром и Вам нужно одеться.
Так вот : процесс одевания можно описать сравнить с разработкой ПО. По такому принципу пишут свой код разработчики функционального программирования, которые создают код с помощью функций. Многие могут возразить: какая же здесь может быть аналогия. А теперь представьте ситуацию, когда Вы одели брюки вместо рубашки, а свитер — вместо штанов. Не очень удобно, ведь правда?
У программистов такая же ситуация: если они неверно напишут код или перепутают логику, то у них выйдет то же самое, что вышло у Вас, когда вы оделись наоборот, только в цифровом варианте. Есть особый тип разработчиков, которые пишут на языке разработки Ассемблер. Для понимания представьте себе предыдущую картину, когда Вам нужно одеться, но вместо одежды на Вашем журнальном столике лежат ткань, игла и нитки , и Вам предстоит сначала сшить свою одежду, чтобы затем ее одеть. У этих ребят действительно талант, их упорству можно только позавидовать.
Теперь, когда Вы знаете отличие разработчиков, пишущих программы на ассемблере ( assembler ) от тех, которые пишут с помощью функций, пришло время описать немного и работу разработчиков объектно-ориентированного программирования (далее ООП). Этих ребят тоже можно разделить на два типа: на тех, которые пытаются все делать, как описанные выше разработчики функционального программирования, и тех, которые пытаются мыслить объектами.
Объекты — то, что Вы видите вокруг себя: дерево, машина, трасса, светофор, здание, человек — являются также объектами для разработчика. В разработке для этого есть много принципов, схем и комбинаций. Например, в ООП существует направление п роблемно-ориентированное проектирование (DDD) ( англ.
Domain — driven design ) . Э то набор принципов и схем, помогающих разработчикам создавать изящные системы объектов. Проще говоря, это процесс создания разработчиком аналогичных объектов реального мира в программные объекты с целью упростить нашу жизнь. Это могут быть сложные банковские системы, системы учета, графические редакторы и т.д.
Возможно, из приведенного выше описания не все поняли, что такое объекты и как ими оперировать разработчику. Да и зачем они ему вообще. Рассмотрим другой пример, с которым можно столкнуться каждый день. Допустим, Вам нужно добраться с точки А в точку B . За точку А для простоты возьмем место Вашего жительства, а за точку B — место Вашей работы.
Для тех, кто живет в больших мегаполисах, такой способ добраться из дому на работу вполне может подойти. Например, я могу доехать на работу как минимум пятью способами и маршрутами. Как в такой задаче найти минимальное время и самый удобный маршрут? Для этого нужно поехать каждым маршрутом, сравнить цену, длительность поездки и выбрать оптимальный. Но что, если задача усложняется?
Например, нам нужно поехать машиной из одного города в другой за сотни тысячи километров. Способ самостоятельной проверки не подходит. Для этого существуют люди, которые придумывают способы решения таких задач, а разработчики делают так, чтобы пользователь просто указал точку А и точку B и получил выстроенный нужный маршрут. В последнем приложении я описал роботу GPS навигатора J . Есть целый раздел дискретной математики, который изучает графы (граф — это совокупность непустого множества вершин и наборов пар вершин; в нашем примере вершины — это остановки транспорта, а также начальный и конечный пункты назначения, а связи или дуги графа — это дорога, которой можно добраться к точке назначения).
Выше я описал одну из задач, которая стоит перед каждым программистом: уметь описывать объекты. Перед ними стоит еще одна большая задача: декомпозиция объектов. Это, по сути, разбор большого объекта на более мелкие объекты. Представьте себе, что Вы программист и видите перед собой автомобиль. Ваша задача — написать цифровой вариант автомобиля с помощью объектов.
Попробуем схематически в общих чертах объяснить, как работает декомпозиция на примере. Разобьём объект «автомобиль» на три главных части , которые далее можем делить на более мелкие объекты . Их на самом деле намного больше, но чтобы понять суть, этого будет вполне достаточно.
Умение правильно компоновать объекты и их правильная декомпозиция — это основа работы успешного программиста. А умение проектировать на основе этих объектов целые системы — это поистине гениально. Разработку программного обеспечения можно сравнить со строительством огромного здания. Каждый разработчик пишет свой модуль, свой «кирпичик» этого здания.
Задача архитектора ПО — это спроектировать это здание. Увидеть и описать его так, чтобы другие разработчики по этому описанию смогли построить то, что представил архитектор. Есть очень интересное сравнение работы разработчиков ПО: “ Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию – Второй закон Вейнберга. ” Пожалуй, на этой оптимистичной ноте я закончу статью. Добро пожаловать в мир цифровых объектов и мир разработки программных продуктов.
Источник: sonyks2007.blogspot.com
Жёсткая (зашитая) логика и программируемая логика
Существует два принципиально разных подхода создания логики приложений:
- жёсткая логика, или, по другому, зашитая в приложении логика;
- программируемая логика.
Жёсткая (зашитая) логика характеризуется созданием логики обработки данных непосредственно в коде программы. После компиляции программа не может быть изменена, а значит и действия по обработке данных тоже. Программы с такой логикой создаются для реализации алгоритмов конкретно поставленной задачи.
Примерами могут служить фильтры, микромодули обработки потоковых данных, парсеры и др. Достоинством программ с жёсткой (зашитой) логикой является высокая скорость обработки данных. Недостаток в том, что при изменении логики необходимо перепроектировать программу заново.
Программируемая логика преодолевает проблему перепроектирования и позволяет пользователю адаптировать приложение под новую задачу. Обычно такое приложение разрабатывается по типу интерпретатора некоего псевдокода. Примерами являются приложения с поддержкой языков GraphQL, SQL и подмножество других языков запросов, CWL (Common Workflow Language), YAWL и многие другие.
Источник: specialistoff.net