Я слышал много раз, что мы не должны смешивать бизнес-логику с другим кодом или такими утверждениями. Я думаю, что каждый отдельный код, который я пишу (шаги обработки я имею в виду), состоит из логики, которая связана с бизнес-требованиями.
Может ли кто-нибудь сказать мне, что именно состоит из бизнес-логики? Как его можно отличить от другого кода? Есть ли простой тест, чтобы определить, что такое бизнес-логика, а что нет?
Просто определите, что вы делаете на простом английском языке. Когда вы говорите что-то по-деловому, например, "заставляйте страдать", "крадите эти деньги", "уничтожайте эту часть земли", вы говорите о бизнес-слое. Чтобы было ясно, все, что вас возбуждает, здесь.
Когда вы говорите "покажите это здесь", "не показывайте это", "сделайте его более красивым", вы говорите об уровне презентации. Это то, что вдохновляет ваших дизайнеров.
Когда вы говорите такие вещи, как "сохранить это", "получить это из базы данных", "обновить", "удалить" и т.д., вы говорите об уровне данных. Это то, что говорит вам, что сохранить навсегда любой ценой.
Вероятно, легче начать, говоря, что не является бизнес-логикой. База данных или доступ к диску не являются бизнес-логикой. Пользовательский интерфейс не является бизнес-логикой. Сетевые коммуникации не являются бизнес-логикой.
Для меня бизнес-логика - это правила, описывающие, как работает бизнес, а не как работает архитектура программного обеспечения. Бизнес-логика также имеет тенденцию к изменению. Например, это может быть бизнес-требование, чтобы каждый клиент имел одну кредитную карту, связанную с их учетной записью. Это требование может измениться, чтобы клиенты могли иметь несколько кредитных карт. Теоретически это должно быть просто изменение бизнес-логики, и другие части вашего программного обеспечения не будут затронуты.
Итак, эта теория. В реальном мире (как вы нашли) бизнес-логика имеет тенденцию распространяться по всему программному обеспечению. В приведенном выше примере вам, вероятно, потребуется добавить другую таблицу в свою базу данных, чтобы хранить дополнительные данные кредитной карты. Вам обязательно нужно будет изменить пользовательский интерфейс.
Пуристы говорят, что бизнес-логика всегда должна быть полностью разделенной, и даже против таблиц "Клиенты" или "Учетные записи" в базе данных. Доведенный до крайности, вы получите невероятно общую, невозможную для поддержания системы.
Определенно есть веский аргумент в пользу сохранения большей части вашей бизнес-логики, а не размазывания ее по всей системе, но (как и в большинстве теорий) вам нужно быть прагматичным в реальном мире.
Я думаю, вы путаете бизнес-логику с вашими требованиями приложения. Это не то же самое. Когда кто-то объясняет логику своего дела, это что-то вроде:
"Когда пользователь покупает элемент, он должен предоставить информацию о доставке. Информация проверяется с помощью правил xyz, после чего он будет получать счет-фактуру и зарабатывать очки, что дает x% скидки для предложений y" (извините за плохой пример)
При реализации этих бизнес-правил вам придется подумать о вторичных требованиях, например о том, как информация будет представлена, как она будет храниться на постоянной основе, о связи с серверами приложений, о том, как пользователь получит счет-фактуру и скоро. Все эти требования не являются частью бизнес-логики и должны быть отделены от него. Таким образом, при изменении бизнес-правил вы будете адаптировать свой код с меньшими усилиями. Это факт.
Иногда презентация реплицирует часть бизнес-логики, в основном, при проверке ввода пользователя. Но он также должен присутствовать на уровне бизнес-логики. В других ситуациях необходимо переместить некоторую бизнес-логику в базу данных, для проблем с производительностью. Об этом говорит Мартин Фаулер здесь.
Чтобы упростить вещи до одной строки...
Бизнес-логика будет кодом, который не зависит от/не будет изменяться с помощью конкретной детали пользовательского интерфейса/реализации.
Это кодовое представление правил, процессов и т.д., Которые определяются/отражают моделирование бизнеса.
Мне не нравятся имена BLL + DAL слоев, они более запутанны, чем поясняют.
Назовите его DataServices и DataPersistence. Это упростит работу.
Службы манипулируют, сохраняются CRUD-уровни (Create, Read, Update, Delete)
Для меня "бизнес-логика" составляет все сущности, представляющие данные, применимые к проблемному домену, а также логику, которая решает "что делать с данными".
Таким образом, он должен действительно состоять из "переноса данных" (не доступа) и "манипуляции данными". Фактически доступ к данным (материал, попадающий в БД) должен быть в другом слое, как и код презентации.
Если он содержит что-либо о таких вещах, как форма, кнопка и т.д., это не бизнес-логика, это слой представления. Если он содержит постоянство файла или базы данных, это DAL. Все, что находится между ними, - это бизнес-логика. На самом деле, что-то не-UI иногда называют "бизнес-логикой", но это должно быть что-то, что касается проблемной области, а не содержания в доме.
Бизнес-логика - это чистая абстракция, она существует независимо от материализации/визуализации данных перед вашим пользователем и не зависит от сохранения базовых данных.
Например, в программном обеспечении для подготовки налогов одна из обязанностей классов бизнес-логики могла бы исчислять налог. Они не будут нести ответственность за отображение отчетов или сохранение и получение налоговой декларации.
@Lars, "services" подразумевает определенную архитектуру.