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