При разработке веб-приложений реализация бизнес-логики может выполняться на клиенте (frontend-часть приложения) или на сервере (backend-часть приложения). В связи с этим, при добавлении логики в приложение нужно понимать, в какой из этих частей приложения требуется или будет наиболее целесообразно внести соответствующие изменения.
В многостраничных (MPA) веб-приложениях на клиенте чаще всего настраивается внешний вид приложения, а также реализуется презентационная логика. Под презентационной логикой мы понимаем реакцию приложения на действия пользователя, которая должна следовать непосредственно за действием. Примером такой логики может служить автозаполнение зависимых полей при изменении независимых, валидация и т.д. В одностраничных (SPA) веб-приложениях, коими являются и Ember-приложения, помимо презентационной логики на клиенте реализуется также и основная часть бизнес-логики. Однако часть бизнес-логики для одностраничных приложений может быть реализована также и на сервере. Чаще всего к этой части бизнес-логики обычно относятся дополнительные действия с данными перед их вставкой, измерением или удалением в базе данных.
В данном разделе мы затронем ту часть бизнес-логики, которая реализуется на стороне сервера.
Создание бизнес-сервера
Для создания бизнес-логики в серверной части приложений, реализованных с использованием фреймворка Flexberry Ember, используют бизнес-серверы - специальные классы на языке C#, методы которых вызываются при определенных событиях, происходящих со связанным объектом данных - это события добавления, изменения или удаления данных. Для того, чтобы связать бизнес-сервер с объектом данных, необходимо внести определенные изменения в структуру модели предметной области во Flexberry Designer. Для этого перейдем в актуальную для нашего приложения стадию и добавим новую диаграмму классов “Бизнес-серверы”:
В диаграмме создайте новый класс OrderBS и измените его стереотип на businessserver:
Далее нужно привязать бизнес-сервер к нужному нам классу. Для этого сохраните и закройте диаграмму “Бизнес-серверы” и перейдите в диаграмму “Сущности”. Здесь необходимо привязать OrderBS к классу Order:
Order → [ПКМ] → ORM: Редактировать свойства → Класс → поле BSClass
В качестве бизнес-сервера выберем созданный нами ранее OrderBS.
Остается только сгенерировать бизнес-сервер. Для этого закрываем с сохранением диаграмму классов “Сущности” и генерируем бэкенд, выбрав проект Shop.BuisnessServers:
Откроем решение (Solution) с именем Shop.sln в Visual Studio:
Мы видим, что там появился новый проект - бизнес-серверы (Shop.BuisnessServers), в который сгенерировался созданный нами бизнес-сервер OrderBS. Откроем соответствующий класс:
По умолчанию в бизнес-сервере генерируется метод **OnUpdate<ИмяКласса>**, который вызывается при выполнении операций вставки, изменения или удаления для соответствующего класса (объекта данных). Однако, пока бизнес-сервер не сопоставлен с классом Order: для этого необходимо также обновить проект с объектами данных. Поэтому, запустим перегенерацию бэкенда еще раз, только на этот раз для объектов:
Откроем класс Order в Visual Studio:
Shop.Objects → Order.cs
Теперь бизнес-сервер OrderBS будет вызываться при любых (OnAllEvents) событиях с экземпляром класса Order.
Запуск backend в режиме отладки
Одним из важных умений при работе с backend-частью Flexberry Ember-приложения (как, впрочем, и любого другого приложения) является умение “дебажить” - запускать приложение в режиме отладки (debug). Данный режим позволяет отслеживать состояние переменных в процессе выполнения кода на бэкенде, а также динамически вносить собственные изменения. До сих пор мы запускали бэкенд приложения без режима отладки (Ctrl + F5).
Для того, чтобы запустить бэкенд приложения в режиме отладки, необходимо выбрать соответствующую конфигурацию в верхней панели и нажать старт:
Запустите приложение в режиме отладки. Одной из ключевых возможностей “дебага” является возможность ставить точки останова (breakpoint / брейкпоинт). Для этого нужно поставить слева от номера строки флажок: перед выполнением этой строки кода программа остановится, ожидая наших дальнейших действий. Поставим брейкпоинт на оператор return в методе OnUpdateOrder (OrderBS):
Проверим, как работает режим отладки. Для этого в приложении откроем Заказ 1 и изменим менеджера на Сидорова (Сидор Сидорович, таб. номер 5). Сохраним.
Автоматически открылось окно Visual Studio, а указанная строка подсветилась. В верхней панели кнопка изменилась на Continue: мы её используем, когда мы будем готовы перейти к следующей точке останова или продолжить выполнение программы. Посмотрим, что представляет собой экземпляр заказа - параметр UpdatedObject. Для этого наведем на него курсор мыши и раскроем его содержимое:
Мы видим те изменения, которые мы внесли в заказ прежде, чем его сохранить. В частности, уже изменена ссылка на объект менеджера.
Закроем просмотр объекта, снимем брейкпоинт и нажмем Continue: мы вернемся к окну браузера.
Если изменения будут внесены в процессе выполнения программы (не в режиме отладки), то даже после сохранения они не будут приняты к выполнению до тех пор, пока вы не перезапустите приложение или не приостановите его (кнопка "пауза" на панели / Break All / Ctrl+Alt+Break). При этом не все изменения могут быть приняты во время приостановки приложения: подключения сторонних библиотек требуют полного перезапуска приложения.
Итог
В дальнейшем при разработке функционала бизнес-сервера мы будем использовать режим отладки и брейкпоинты, чтобы контролировать происходящее в бизнес-сервере.