Бизнес-логика приложения — это описание схем, по которым приложение взаимодействует с пользователем. Когда пользователь подписывается, или заполняет форму заказа, или просто авторизуется, все эти действия обрабатываются «под капотом» приложения в определенном порядке.
Какие данные вам нужно запросить? Соответствуют ли введенные данные указанному формату? Что происходит после того, как пользователь нажимает кнопку «Подтвердить»? У него вообще есть права доступа к этой операции? На все эти и многие другие вопросы можно ответить, изучив, как устроена бизнес-логика конкретного приложения.
Самый простой пример: администратор авиакомпании (пользователь) регистрирует пассажира на рейс (вносит информацию в базу данных).
Что делает пользователь:
1. Открывает информацию о выбранном рейсе, переходит к списку уже зарегистрированных пассажиров, нажимает «Зарегистрировать пассажира».
2. Заполняет регистрационную форму: вводит номер рейса, выбирает пассажира, указывает место и статус регистрации.
3. Нажимает кнопку «Подтвердить».
4. Видит нового пассажира в общем списке.
Как это выглядит с точки зрения бизнес-логики приложения:
1. Приложение проверяет, авторизован ли пользователь и имеет ли он права доступа к выбранной странице, а также операции регистрации.
2. Ждет, пока пользователь заполнит форму.
3. Обрабатывает введенные данные:
а. Проверяет, соответствуют ли введенные данные требованиям приложения (эти требования предопределены программистом): например, поле «Номер рейса» должно содержать целое число.
б. Получает информацию из базы данных: например, о рейсе и связанных с ним регистрациях (чтобы внести изменения), пассажире (чтобы проверить, действительно ли этот пассажир находится в базе данных).
в. Показывает сообщения об ошибках, если поля заполнены неправильно.
д. Отправляет информацию в базу данных, давая команды на создание в ней новых записей или обновление существующих.
4. Отображает обновленную информацию на экране.
Общая логика приложения выстраивается бизнес-процессами — схемами, описывающими конкретные операции в системе: создание записи о пассажире, добавление в систему нового рейса, редактирование регистрационной информации.
В классическом программировании блоки кода используются для описания всех процессов. Многие из них написаны по шаблонам — просто используются в разной последовательности и для работы с разными данными.
Из-за такой «шаблонности» в бескодовой разработке стало возможным использовать средства визуального программирования — конструкторы бизнес-логики. Они помогают выбрать нужные блоки, настроить и расположить их в нужной последовательности и даже создать некоторые блоки автоматически, в зависимости от настроек других компонентов приложения. Суть в готовой бизнес-логике без необходимости тратить часы и часы на строки кода.
О том, как настроить бизнес-логику на платформе AppMaster.io , вы можете узнать из видео бизнес-процесса .
Источник: appmaster.io
Бизнес-логика
Бизнес-логика (логика предметной области) — совокупность правил, принципов, зависимостей поведения объектов предметной области системы.
Размещение уровня бизнес-логики в трёхуровневой системе.
К бизнес-логике относятся, к примеру, формулы расчета ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отсылка е-мейла руководителю проекта по окончанию выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.
В фазе бизнес-моделирования и разработки требований бизнес-логика может описываться в виде текста, концептуальных аналитических моделей предметной области, бизнес-правил, разнообразных алгоритмов, диаграмм деятельности, графов и диаграмм перехода состояний, моделей бизнес-процессов. В фазе анализа и проектирования системы бизнес-логика воплощается в классах и методах классов, в случае использования объектно-ориентированных языков программирования, или процедур и функций, в случае применения процедурных языков.
На жаргоне разработчиков ПО бизнес-логикой также называются программные модули, её реализующие, и уровень системы, на котором эти модули находятся (Business Logic Layer, Domain Logic Layer).
В многоуровневых информационных системах этот уровень взаимодействует с нижележащим уровнем инфраструктурных сервисов (Infrastructure Layer), например, интерфейсом к базе данных или файловой системе (Data-Access Layer, DAL) и вышележащим уровнем сервисов приложения (Application Services Layer), который уже, в свою очередь, взаимодействует с уровнем пользовательского интерфейса (User Interface Layer) или внешними системами.
Источник: www.tadviser.ru
Разделение бизнес-логики и UI во Flutter с помощью BLoC-архитектуры
Flutter — динамично развивающийся фреймворк для написания кроссплатформенных приложений. Несмотря на свою молодость (первая стабильная версия Flutter 1.0 была представлена всего лишь 4 декабря 2018 года, то есть чуть больше года назад на момент публикации статьи), он приобрел немало сторонников, и его популярность только растет. Сегодня мы хотели бы рассказать об одной из самых популярных среди Flutter-разработчиков архитектур, которая была разработана в Google, и называется — BLoC.
Что такое BLoC
Давайте разберемся с основной терминологией. BLoC — это акроним от «Business Logic Component» (компонент бизнес-логики). Как следует из названия, это класс, отделяющий бизнес-логику приложения от пользовательского интерфейса. Такой компонент содержит код, который можно повторно использовать где угодно: в другом модуле, на другой платформе, в другом приложении. Если вы до этого работали с архитектурой MVVM, то можете провести аналогию и сравнить Bloc с ViewModel — они похожи по своему назначению.
Обратите внимание на разницу в написании терминов. Здесь и далее употребляется BLoC, когда речь идет об архитектуре, и Bloc — когда о классе в программе.
Отделение UI от бизнес-логики для Flutter жизненно необходимо. Согласитесь, что карабкаться вверх-вниз по дереву виджетов (UI-компонентов) в поисках нужной вам логики — не самая приятная вещь. Особенно, если верстка и так содержит очень много кода и разбросана по разным файлам.
Кроме того, если мы следуем заветам Clean Architecture (а мы им следуем, не так ли?), то в нашем UI вообще не должно быть ничего лишнего. Равно как и бизнес-логика ничего не должна знать про UI, который к ней обращается. Благодаря такому тщательному разделению ответственностей мы получаем полностью изолированный компонент, который можно легко тестировать независимо от UI и использовать в другом окружении. Этот компонент и есть наш Bloc.
Одной из отличительных особенностей паттерна является то, что он полностью базируется на реактивности. Что это значит? Реактивное программирование — это программирование с асинхронными потоками данных.
В традиционном императивном стиле мы обычно пишем код следующего содержания: вот текстовое поле, назначаем ему обработчик, реагирующий на ввод нового символа, в обработчике добавляем объект, у которого вызываем метод обновления текстового поля в модели. Мы четко описываем каждый шаг. В реактивном подходе все выглядит немного иначе. Текстовое поле связывается с конкретной переменной в модели. И как только пользователь начинает что-то печатать, эта переменная сразу принимает то значение, которое сейчас содержится в текстовом поле.
Для реализации реактивных сценариев язык Dart по умолчанию предлагает класс StreamController. Он позволяет нам моделировать поток данных с помощью двух составляющих — sink (входной поток, куда пользователь добавляет события) и stream (выходной поток, который слушают один или несколько объектов и реагируют на изменения). Пример описания входа-выхода для экрана в коде Bloc-а выглядит следующим образом:
final StreamController_nameController = StreamController(); // описываем геттер для входного потока (sink) Sink get inName =>_nameController.sink; // описываем геттер для выходного потока (stream) Stream get outName =>_nameController.stream;
Отдельные геттеры удобно делать по следующим причинам. Во-первых, так гораздо проще, чем каждый раз писать nameController.sink, во-вторых, вы даете входу/выходу осмысленное имя, что позволяет легче понять его назначение и тем самым улучшает читабельность.
Код метода build для вашего виджета может выглядеть так:
Здесь мы создаем специальный виджет StreamBuilder. Первым аргументом указываем поток, который поставляет данные нашему виджету, вторым — функцию, «собирающую» виджет на основе отрисовочного контекста и данных, асинхронно приходящих из потока.
Для реализации BLoC часто используются уже готовые библиотеки, например, эта. Нашей же команде она показалась слишком тяжеловесной, поэтому мы воспользовались кастомной, упрощенной реализацией, описанной в этой статье. Рассмотрим ее основные положения.
Знакомство с BlocProvider
Каждый Bloc поддерживает общий интерфейс BlocBase, содержащий в себе только один обязательный к реализации метод dispose. Он нужен, чтобы не забыть реализовать освобождение ресурсов, занятых Bloc-ом, например, закрыть активные потоки. Выглядит он так:
abstract class BlocBase
Для того чтобы вы могли получить доступ к Bloc-у из любого узла дерева виджетов, корнем этого дерева становится такая сущность, как BlocProvider. Рассмотрим ее код:
Идея заключается в том, что наш провайдер, точно такой же виджет, который состоит из двух слагаемых: Bloc, к которому будут обращаться виджеты, и дерево виджетов, которое мы видим на экране. Для доступа к Bloc-у в методе виджета build вам нужно написать так:
Доступ к Bloc-у под капотом реализован очень просто. Мы движемся вверх по иерархии виджетов в рамках BuildContext, пока не встретим BlocProvider. Как только это произошло, мы можем вернуть Bloc этого провайдера.
Небольшое уточнение по поводу оптимизации. Поиск по иерархии виджетов имеет вычислительную сложность O (n). Если ваш провайдер расположен относительно близко к виджету, который запросил Bloc, такая операция не займет много времени. Однако в случае, когда ваш виджет имеет большую глубину вложенности, а доступ к Bloc-у ему требуется часто, это может сказаться на производительности. Тогда есть смысл подумать о том, чтобы кэшировать ссылку на Bloc, например, передавая его как аргумент в конструктор виджета.
Пример реализации
Рассмотрим, как работа с BLoC-архитектурой может выглядеть на практике. Перепишем пример, который по умолчанию генерируется при создании Flutter-проекта. Так как здесь всего один экран, у нас будет один виджет MainScreen с прилагающимся к нему MainBloc.
У MainBloc есть входной поток с UI событиями (в нашем случае нажатия на кнопку «+») и выходной поток со значением счетчика нажатий. Само значение счетчика counter из State должно переехать сюда, поскольку оно — часть бизнес-логики. В результате получаем следующий код для MainBloc:
Если создание отдельного потока для UI-событий вам кажется излишним, то вы можете написать отдельный метод-обработчик нажатия на кнопку «+» (onIncrementButton) и вызывать его напрямую.
Теперь вынесем код виджета из main.dart в MainScreen и интегрируем в него наш MainBloc:
Обратите внимание, текстовый виджет со значением счетчика теперь находится в StreamBuilder, который подписан на поток из Bloc-а. При нажатии на кнопку в Bloc прокидывается соответствующее событие (на ваше усмотрение, через поток или обработчик). Bloc обрабатывает событие, увеличивая хранящийся в нем счетчик нажатий на 1. После чего значение этого счетчика передается в другой поток, на который подписан виджет на стороне UI. StreamBuilder получает новое состояние из потока (AsyncSnapshot) и перерисовывает свое содержимое с новыми данными.
Наконец, создадим BlocProvider для нашего экрана. Вынесем этот код в main.dart:
Запускаем приложение и проверяем его работоспособность.
Код проекта вы можете посмотреть здесь.
Чек-лист по работе с BLoC-архитектурой
Итак, алгоритм работы при создании новых экранов с использованием BLoC-архитектуры выглядит следующим образом:
- Создать Bloc для конкретного экрана.
- Описать его входы и выходы в виде потоков.
- Реализовать требуемую бизнес-логику.
- Создать новый экран.
- Поместить в корень дерева виджетов BlocProvider, передать ему экземпляр реализованного Bloc-а и, собственно, виджеты, которые будут отображаться на экране.
- Реализовать экран, используя по необходимости StreamBuilder-ы, подписанные на выходы из Bloc-а.
Разумеется, никто не заставляет вас ограничивать себя исключительно StreamBuilder-ами. Более того, в случае, когда для отрисовки виджета вам нужно просто один раз синхронно получить данные из Bloc-а, «плодить» stream-ы даже нерационально. А для разовой подгрузки данных по сети можно использовать, например, FutureBuilder. Поэтому изучайте, экспериментируйте, создавайте. В следующей статье мы расскажем, как наша команда переходила от привычного паттерна VIPER к BLoC и с какими сложностями мы при этом столкнулись.
Источник: inostudio.com
