Как отделить небезопасную логику от критической?
Где живет бизнес-логика и логика пользовательского интерфейса?
Это бизнес-правила, проверки и вычисления, которые работают с данными, когда они вводятся в информационную систему или отображаются в ней. - Мартин Фаулер
Ваши услуги относятся к бизнес-уровню. Бизнес-правила, которые вы применяете к данным, и делаете выводы на основе данных.
Ваши контроллеры находятся на уровне пользовательского интерфейса и отвечают за пользовательский интерфейс, страницы и простую логику вокруг них.
Почему важен бизнес-уровень?
Давайте объясним на языке непрофессионала. Лоран С. есть отличное объяснение по этой теме. Я постараюсь передать его слова с приложением моего собственного мнения.
Давайте посмотрим на процесс загрузки грузовика. Есть два рабочих.
Один загружает машину, рабочий, один смотритель, смотритель. Worker представляет собой логику представления. Супервайзер - бизнес-правила.
Супервайзер заботится о весе грузовика. Сколько грузовик может перевезти? - бизнес-правило.
Рабочий кладет ящики в грузовик. Рабочий решает куда поставить ящик - логика представления.
Когда у вас нет руководителя, вам нужно научить работника правилам. Допустим, это простое правило, 1 тон - это предел веса.
Ваш бизнес расширяется, вы нанимаете больше сотрудников (мобильные, настольные, другие устройства). Вы учите их этому правилу.
Приходят новые правила. Теперь нужно придерживаться законов страны. Законы меняются слишком часто.
У вас есть два варианта:
- Нанять юристов, чтобы заполнить грузовик.
- Рабочие вызывают юриста.
Допустим, вы выбираете юристов, чтобы заполнить свой грузовик. Они знают законы и могут определить предел веса.
С точки зрения программного обеспечения, вы вкладываете больше логики в свой презентационный слой.
Другой вариант более выгоден. Рабочие звонят юристу, получают ответ, продолжают ли погрузки или останавливаются.
С точки зрения программного обеспечения, добавьте бизнес-правила к бизнес-уровню, который пользовательский интерфейс может запрашивать для получения информации.
Что не так в пользовательском интерфейсе?
Не обманывайте клиентов. Взгляните на эту статью ниже.
Не лгите об активных покупателях. Любой разработчик увидит эту ложь.
Решите это на бэкэнде. Посмотрите на активные сеансы и дополнительную информацию, чтобы идентифицировать продукт. Товар, на который смотрит покупатель.
Запросить данные у серверной части. Подсчитайте активных клиентов и ответьте на уровень пользовательского интерфейса.
Не выполняйте свою бизнес-логику на внешнем интерфейсе. Например, не рассчитывайте продвижение на веб-интерфейсе.
Действуйте в соответствии с данными на сервере. Скрыть конфиденциальную информацию от внешнего интерфейса.
Держите свои правила промо в бэкэнде. Акции - это условия и действия. Вам действительно нужен какой-то механизм правил, чтобы решить, действительно ли продвижение по службе.
После того, как решение будет принято, примените продвижение и верните страницу. При автономном подходе вы вызываете промо-API для получения информации.
Кажется логичным, но у нас есть плохие примеры.
Что уместно на уровне пользовательского интерфейса?
Получите доступ к бэкэнд-логике. Отправляйте промокоды. Получите ответ. Или встроить в страницу примененное продвижение.
Вызовите серверную часть, попросите соответствующих активных пользователей подсчитать и представьте это в пользовательском интерфейсе. Бэкэнд должен рассчитать это количество. Не jQuery.
Заключение
Это несколько примеров того, как бороться с нежелательным поведением.
Соблюдайте свои критические правила на бэкэнде. Проверяйте акции, разрабатывайте алгоритмы, на бекенде. Менее важные из них могут быть размещены во внешнем интерфейсе. Создайте условную стилизацию на этом слое.
Благодаря этому вы можете быть уверены, что ваше приложение защищено. Защищен от нежелательного поведения.
Ресурсы
Большая часть этой темы возникла из этого вопроса.
