Как описать бизнес логику приложения
Я слышал, что люди много говорят о бизнес-логике на работе и в Интернете, и я прочитал несколько вопросов на этом сайте об этом, но этот термин все еще не имеет большого смысла для меня. Например, вот некоторые (перефразированные) утверждения, которые я часто вижу:
«Бизнес-логика - это часть вашей программы, которая кодирует реальные бизнес-правила». Большинство определений, которые я прочитал, являются круглыми, как это.
«Бизнес-логика - это все уникальное для вашего конкретного приложения». Я не понимаю, чем это отличается от «ваше конкретное приложение - не что иное, как бизнес-логика», если только мы случайно не заново изобрели набор колес, для которых мы могли бы использовать существующее стороннее программное обеспечение. Отсюда и название вопроса.
«Должен быть уровень бизнес-логики выше уровня доступа к данным и ниже уровня графического интерфейса». В коде, который я пишу, инициаторы доступа к базе данных должны знать, к каким данным они должны обращаться, и код пользовательского интерфейса должен знать много о том, что он отображает, чтобы правильно отображать его, и между ними действительно ничего не нужно делать. эти два места, кроме передачи больших двоичных данных между клиентом и сервером. Так что же на самом деле должно входить в уровень бизнес-логики?
«Бизнес-логика должна быть отделена от логики представления». Большинство запросов к функциям, которые мы получаем, должны изменить логику представления по деловым причинам. Если одно из бизнес-правил состоит в том, чтобы по умолчанию отображать цены государственных облигаций США в 32-й записи (при этом пользователь также может настраивать пользовательский интерфейс), логике представления необходимо, по крайней мере, знать, что это правило существует, если оно не реализовано полностью. Кроме того, похоже, что основная часть UX-дизайна помогает пользователю понять бизнес-правила, которые пытается реализовать наше программное обеспечение.
Возможно ли, что я на самом деле в команде, которая занимается только бизнес-логикой, а вся некоммерческая логика выполняется другими командами? Или вся концепция «бизнес-логики» как отдельной сущности применима только для определенных приложений или архитектур?
Чтобы конкретизировать ответы: представьте, что вам нужно переопределить приложение Domino's Pizza. Что такое бизнес-логика и какова не-бизнес-логика этого приложения? И как можно было бы поместить эту бизнес-логику для заказа пиццы в ее собственный «слой» кода, без того, чтобы большая часть информации о пицце перетекла на уровни доступа к данным и представления?
Обновление: я пришел к выводу, что моя команда, вероятно, делает 90% кода пользовательского интерфейса, и большая часть - но не все - того, что вы бы назвали бизнес-логикой, исходит от других команд или компаний. В основном наше приложение для мониторингафинансовые данные и почти все функции позволяют пользователям настраивать, какие данные они видят и как они их видят. Покупки или продажи не ведутся (хотя мы немного интегрируемся с другими приложениями нашей компании, которые это делают), а фактические данные поступают от множества внешних источников. Но мы разрешаем пользователям делать такие вещи, как отправка копий своих «мониторов» другим пользователям, поэтому детали того, как мы поступаем, вероятно, квалифицируются как бизнес-логика. На самом деле есть мобильное приложение, которое в настоящее время общается с некоторым из нашего внутреннего кода, и я точно знаю, какой частью нашего кода веб-интерфейса я хотел бы поделиться им с нашим пользовательским интерфейсом в идеальном мире (в основном это M в нашем квази-MVC), поэтому Я предполагаю, что это BLL для нас.
Я принимаю ответ user61852, поскольку он дал мне гораздо более конкретное понимание того, что «бизнес-логика» делает и не относится к ней.
Давайте разберемся, что же такое бизнес-логика:
Бизнес-логика описывает работу всех бизнес-процессов, существующих в продукте.
И да и нет. Под термином «Бизнес-логика» действительно понимают UX, но есть существенный нюанс.
Обычно к UX-дизайну относятся только пользовательские сценарии. Тогда как бизнес-логика описывает именно бизнес-процессы, происходящие под капотом UX с сугубо технической точки зрения.
Если бизнес-логика отвечает на вопрос:
«Как продукт должен работать технически?»
То UX-дизайн отвечает на вопрос:
«Как пользователь будет пользоваться продуктом и как сделать этот процесс максимально удобным и быстрым?».
UX-дизайн рассматривает ситуации (сценарии), с которыми сталкивается пользователь в процессе использования продукта; проблемы, которые продукт должен решить, чтобы им было интересно, выгодно или, как минимум, удобно пользоваться.
Бизнес-логика, наоборот, есть набор различных бизнес-процессов, возникающих внутри продукта. Они связаны между собой сугубо технически и никак не связаны с UX-дизайном.
UX-дизайн
То, как видит логику работы части приложения UX-дизайнер.
- Пользователь очень хочет смуззи!
- Он открывает приложение.
- Выбирает смуззи, указывает количество и нажимает кнопку «Купить»
- Ввводит адрес доставки, адрес проверяется, переходит к оплате смуззи.
- Оплачивает смуззи.
- Получает подтверждение покупки и видит информацию о дате и времени доставки, и ждет курьера.
Бизнес-логика
То, что должен видеть хороший UX-дизайнер и продакт менеджер.
- Пользователь авторизован / не авторизован
- Пользователь выбирает смуззи из всех доступных на данный момент
- Пользователь указывает характеристики смуззи
- Система проверяет, что для смуззи есть ингредиенты и запускает пользователя в процесс покупки смуззи.
- Пользователь указывает адрес доставки.
- Система проверяет условия доставки и можно ли вообще доставить смуззи за МКАД по указанному адресу.
- Пользователь переходит к оплате смуззи.
- Если пользователь авторизован, то его направляют на выбор способа оплаты.
- Если пользователь не авторизован, то его направляют на регистрацию.
- Пользователь выбирает способ оплаты.
- Пользователь указывает «Оплата наличными». Пользователь может выбрать и другой вариант.
- Пользователь указывает «Оплата банковской картой».
- Пользователь вводит данные банковской карты и нажимает на кнопку «Оплатить».
- Платежный шлюз проверяет реквизиты платежа
- Платежный шлюз принимает оплату и сообщает системе, что платеж принят.
- Заказ поступает в ближайшую к клиенту смуззишную.
- Заказ готовится.
- Заказ готов и передается курьеру.
- Курьер доставляет заказ пользователю.
- Курьер отмечает факт доставки заказа.
- Данные о завершении заказа попадают в систему.
- Система направляет пользователю предложение оценить сервис.
В реальной жизни бизнес-процесс устроен несколько сложнее, но общая идея и различие с UX-дизайном должны быть понятно.
Термин «Бизнес-логика» вы вряд ли услышите в стартапе, нацеленном на продажу смуззи, зато этот термин в широком ходу в B2B и интеграторах.
Теперь вас точно не испугаешь замысловатым вопросом «А как устроена бизнес-логика?». Помните, что бизнес-логика – это про весь механизм работы продукта, а UX-дизайном является лишь то, что по факту увидит пользователь в интерфейсе, в email и sms, отправленные вашим продуктом.
Бизнес-логика приложения – это, по сути, описание схем, по которым приложение взаимодействует с пользователем. Когда пользователь оформляет подписку, или заполняет форму заказа, или просто авторизуется – все эти действия обрабатываются «под капотом» приложения в определенном порядке.
Какие данные нужно запросить? Соответствуют ли введенные данные заданному формату? Что произойдет после того, как пользователь нажмет кнопку «Подтвердить»? А есть ли вообще у него права доступа к данной операции? На все эти и многие другие вопросы можно ответить, изучив, как построена бизнес-логика конкретного приложения.
Простейший пример: администратор авиакомпании (пользователь) регистрирует пассажира на рейс (вносит информацию в базу данных).
2.Заполняет форму регистрации: вводит номер рейса, выбирает пассажира, указывает место и статус регистрации.
3.Нажимает кнопку «Подтвердить»
4.Видит нового пассажира в общем списке.
Как это выглядит с точки зрения бизнес-логики приложения:1.Приложение проверяет, авторизован ли пользователь и имеет ли права доступа к выбранной странице, а также операции регистрации.
2.Ждет, пока пользователь заполнит форму.
3.Обрабатывает введенные данные:
a. Проверяет, соответствуют ли введенные данные требованиям приложения (эти требования заранее прописаны программистом): например, в поле «Номер рейса» должно быть целое число.
b. Получает из базы данных информацию: например, о рейсе и связанных с ним регистрациях (чтобы внести изменения), пассажире (чтобы проверить, действительно ли этот пассажир есть в базе данных).
d. Отправляет информацию в базу данных, отдавая команды на создание в ней новых записей или обновлении существующих.
4.Выводит обновленную информацию на экран.
Общая логика приложения строится из бизнес-процессов – схем, описывающих конкретные операции в системе: создание записи о пассажире, добавление в систему нового рейса, редактирование информации о регистрации.
Когда речь идет о классическом программировании, то для описания всех процессов используются блоки кода. Многие из них пишутся по шаблонам – просто используются в разной последовательности и для работы с разными данными.
Именно благодаря этой «шаблонности» в no-code разработке появилась возможность использовать инструменты визуального программирования – так называемые дизайнеры бизнес-логики. Они помогают выбрать нужные блоки, скомпоновать в нужной последовательности, настроить. И даже создать некоторые блоки автоматически, в зависимости от настроек других компонентов приложения. Итог – готовая бизнес-логика без необходимости проводить многие часы над строками кода.
Шаблон MVC описывает простой способ построения структуры приложения, целью которого является отделение бизнес-логики от пользовательского интерфейса. В результате, приложение легче масштабируется, тестируется, сопровождается и конечно же реализуется.
Не совсем ясно, что означает этот термин
Бизнес-логика - это логика доменной модели - все, что в вашем приложении происходит в терминах предметной области.
Например, на SO - это все действия с пользователями, вопросами, ответами, плюсы, минусы и т.д.
Скрыть кнопку "Оставить комментарий" если текущий пользователь не имеет право оставлять комментарии - особенности представление данных (флага из модели) - во view.
MVC позволяет выделить "не-бизнес" логику, связанную с пользовательским интерфейсом:
- вызовы методов модели по определенным действиям пользователя
- отображение/скрытие контролов
- подготовку данных к отправке на клиента.
. и поместить логику представления в отдельный кусок приложения - Controller.
тем самым оставив в модели "чистую" бизнес-логику, не привязанную к интерфейсу пользователя.
Стоит отметить, что ссылка в вопросе ведет на статью, иллюстрированную диаграммой Classic MVC. Реально в Web используется более современный вариант паттерна - MVC Model2 - и его производные. Его отличие - View не взаимодействует с моделью напрямую.
Взаимодействие в современном MVC выглядит вот так:
Бизнес-логика - то же самое что и логика предметной/доменной/прикладной области. Допустим, вы программируете софт для приюта животных и для детского приюта.
По бизнес-логике приюта для животных, предположим, котика, которого за неделю не забрали новые хозяева, надо усыпить. А до этого его надо кормить, поить и спать укладывать.
По бизнес-логике детского приюта - ребенка надо кормить, поить и спать укладывать. В него нельзя втыкать шприц со смертельной дозой морфия.
При этом все структуры данных, алгоритмы и т.д. - в двух программах практически одинаковы. Кроме вот этой маленькой детали.
"ЭТОТ один ИФЧИК решил СУДЬБУ КОТЕЙКИ", или, например "начинающий программист УБИЛ младенца ВЕКТОРОМ"
Если вы перепутаете бизнес-логику приюта для животных и детского приюта, и усыпите ребенка, а котенку подарите куклу, вы, надеюсь, попадете в тюрячку, там вам все за ООП расскажут.
Не важно, бизнес это, расчет конфигурации молекул, приют или управление кораблем. Бизнес-логика - это та самая часть, которая в итоге должна работать правильно и надежно, та, результатов которой ждет заказчик (котенок, ребенок)
Если не отделять, допустим интерфейс от бизнес-логики, то вместо нажатия кнопки "отдать ребенка новым родителям" или "усыпить котенка", на двух аккуратных - почти похожих - пультах управления (интерфейсах) вы будете бегать туда-сюда, пытаясь понять, кого утопить, кого усыпить, кого отдать новым родителям и почему ничего не работает.
Вы не отделили интерфейс (панель управления для запуска котят на луну) от бизнес-логики и все запуталось.
Ну, я предупреждал.
Используете вы синглтоны, очереди, базы данных, флэт-файлы, микросервисы - не важно - важно, чтобы бизнес-логика работала правильно.
Под правильно подразумевается корректность результатов в приемлемое время. Все остальное ваших заказчиков не интересует. До тех пор, пока они не являются вашими владельцами.
Именно поэтому вы можете продавать очень плохой - с точки зрения программиста - софт клиентам, но с трудом сможете построить на нем надежную систему. Требования бизнес-логики может быть и выполняются, но поддерживать этот код невозможно
P.S. Маленький исторический экскурс. Бизнес-логикой это называется потому, что в Нормальном Мире, во Внешней Империи, программирование в коммерции и корпорациях развивалось еще с 50х-60х годов: банки, страховые агентства, туроператоры, медицина.
Т.е. тебе платили за то, чтобы ты внедрил требования конкретного бизнеса
Хорошо, что это бизнес-логика, а не партийная логика, как в Северной Корее.
В этом учебнике мы посмотрим, как централизовать бизнес-правила на уровне бизнес-логики (BLL), который служит посредником для обмена данными между уровнем представления и DAL.
Введение
Уровень доступа к данным (DAL), созданный в первом учебнике , четко отделяет логику доступа к данным от логики представления. Однако, хотя DAL четко отделяет сведения о доступе к данным от уровня представления, он не применяет никаких бизнес-правил, которые могут применяться. Например, для нашего приложения мы можем запретить изменение полей CategoryID или SupplierID таблицы Products , если для поля Discontinued задано значение 1, или же можно применить правила стажа, запрещая ситуации, в которых сотрудник управляется кем-то, кто его нанимает. Другой распространенный сценарий — авторизация, возможно, только пользователи определенной роли могут удалять продукты или изменять UnitPrice значение.
В этом учебнике мы посмотрим, как централизовать эти бизнес-правила в слое бизнес-логики (BLL), который служит посредником для обмена данными между уровнем представления и DAL. В реальных приложениях слой BLL должен быть реализован в виде отдельного проекта библиотеки классов. Однако в этих учебных курсах мы реализуем слой BLL как набор классов в папке App_Code , чтобы упростить структуру проекта. На рис. 1 показаны архитектурные отношения между уровнем представления, BLL и DAL.
Рис. 1. слой BLL отделяет уровень представления от уровня доступа к данным и накладывает бизнес-правила
Шаг 1. Создание классов BLL
Наш слой BLL будет состоять из четырех классов — по одному для каждого адаптера таблицы в DAL; Каждый из этих классов BLL будет иметь методы для извлечения, вставки, обновления и удаления из соответствующего TableAdapter в DAL, применяя соответствующие бизнес-правила.
Для более четкого разделения классов, связанных с DAL и BLL, давайте создадим две вложенные папки в папке App_Code , DAL и BLL . Просто щелкните правой кнопкой мыши папку App_Code в обозреватель решений и выберите пункт Создать папку. После создания этих двух папок переместите типизированный набор данных, созданный в первом учебнике, в подпапку DAL .
Затем создайте четыре файла класса BLL во вложенной папке BLL . Для этого щелкните подпапку BLL правой кнопкой мыши, выберите пункт Добавить новый элемент и выберите шаблон класса. Назовите четыре класса ProductsBLL , CategoriesBLL , SuppliersBLL и EmployeesBLL .
Рис. 2. добавление четырех новых классов в папку App_Code
Теперь добавим методы к каждому из классов, чтобы просто создать оболочку для методов, определенных для адаптеров таблиц TableAdapter, из первого руководства. Сейчас эти методы просто вызываются непосредственно в DAL; Позже мы вернемся к добавлению любой необходимой бизнес-логики.
Если вы используете Visual Studio Standard Edition или более поздней версии (то есть не используете Visual Web Developer), при необходимости можно спроектировать классы визуально с помощью конструктор классов. Дополнительные сведения об этой новой функции в Visual Studio см. в блоге конструктор классов .
Для класса ProductsBLL нужно добавить всего семь методов:
- GetProducts() возвращает все продукты
- GetProductByProductID(productID) возвращает продукт с указанным ИДЕНТИФИКАТОРом продукта
- GetProductsByCategoryID(categoryID) возвращает все продукты из указанной категории
- GetProductsBySupplier(supplierID) возвращает все продукты указанного поставщика
- AddProduct(productName, supplierID, categoryID, quantityPerUnit, unitPrice, unitsInStock, unitsOnOrder, reorderLevel, discontinued) вставляет новый продукт в базу данных, используя переданные значения; Возвращает ProductID значение вновь вставленной записи
- UpdateProduct(productName, supplierID, categoryID, quantityPerUnit, unitPrice, unitsInStock, unitsOnOrder, reorderLevel, discontinued, productID) обновляет существующий продукт в базе данных, используя переданные значения; Возвращает true , если была обновлена ровно одна строка, false в противном случае
- DeleteProduct(productID) удаляет указанный продукт из базы данных
Методы, которые просто возвращают данные GetProducts , GetProductByProductID , GetProductsByCategoryID и GetProductBySuppliersID , довольно просты, так как они просто вызывают DAL. Хотя в некоторых сценариях могут существовать бизнес-правила, которые необходимо реализовать на этом уровне (например, правила авторизации на основе вошедшего в систему пользователя или роль, к которой принадлежит пользователь), мы просто оставляем эти методы как есть. Для этих методов BLL выступает в качестве прокси-сервера, через который уровень представления данных обращается к базовым данным уровня доступа к данным.
Все три метода возвращают логическое значение, указывающее, была ли строка вставлена, обновлена или удалена, так как операция может не привести к затронутой строке. Например, если разработчик страницы вызывает DeleteProduct передачи ProductID несуществующему продукту, инструкция DELETE , выданная базе данных, не будет оказывать влияния, поэтому метод DeleteProduct возвратит false .
Затем в AddProduct и UpdateProduct код создает экземпляр ProductsRow и заполняет его только что переданными значениями. При назначении значений столбцам данных DataRow могут возникать различные проверки на уровне полей. Таким образом, ручное помещение переданных значений обратно в DataRow позволяет гарантировать, что данные передаются в метод BLL. К сожалению, строго типизированные классы DataRow, создаваемые Visual Studio, не используют типы, допускающие значение null. Вместо этого, чтобы указать, что определенный DataColumn в DataRow должен соответствовать NULL значению базы данных, необходимо использовать метод SetColumnNameNull() .
В UpdateProduct мы сначала загружаем в продукт для обновления с помощью GetProductByProductID(productID) . Хотя это может показаться ненужным обращением к базе данных, это дополнительное путешествие будет оправдано в будущих руководствах, иссвященных оптимистичному параллелизму. Оптимистичный параллелизм — это способ убедиться, что два пользователя, которые одновременно работают с одними и теми же данными, не перезапишут изменения, внесенные другими пользователями. При извлечении всей записи также упрощается создание в BLL методов обновления, которые изменяют только подмножество столбцов DataRow. При рассмотрении класса SuppliersBLL мы увидим такой пример.
Добавление других классов
По завершении класса ProductsBLL нам по-прежнему нужно добавить классы для работы с категориями, поставщиками и сотрудниками. Уделите время созданию следующих классов и методов с помощью концепций из приведенного выше примера:
CategoriesBLL.cs
- GetCategories()
- GetCategoryByCategoryID(categoryID)
SuppliersBLL.cs
- GetSuppliers()
- GetSupplierBySupplierID(supplierID)
- GetSuppliersByCountry(country)
- UpdateSupplierAddress(supplierID, address, city, country)
EmployeesBLL.cs
- GetEmployees()
- GetEmployeeByEmployeeID(employeeID)
- GetEmployeesByManager(managerID)
Один из методов стоит отметить как метод UpdateSupplierAddress SuppliersBLL класса. Этот метод предоставляет интерфейс для обновления только сведений об адресе поставщика. На внутреннем уровне этот метод считывает объект SupplierDataRow для указанного supplierID (используя GetSupplierBySupplierID ), устанавливает связанные с адресом свойства, а затем вызывает метод Update SupplierDataTable . Ниже приведен метод UpdateSupplierAddress .
Сведения о завершении реализации классов BLL см. в статье загрузка этой статьи.
Шаг 2. доступ к типизированным наборам данных с помощью классов BLL
В первом учебном курсе мы увидели примеры работы непосредственно с типизированным набором данных программным способом, но с добавлением наших классов BLL уровень представления должен работать с BLL. В AllProducts.aspx примере из первого руководства ProductsTableAdapter использовалась для привязки списка продуктов к GridView, как показано в следующем коде:
Чтобы использовать новые классы BLL, все, что нужно изменить, — это первая строка кода, просто заменяющая объект ProductsTableAdapter объектом ProductBLL :
Доступ к классам BLL также можно получить декларативно (как и типизированный набор данных) с помощью ObjectDataSource. Мы будем обсуждать ObjectDataSource более подробно в следующих руководствах.
Рис. 3. список продуктов отображается в элементе управления GridView (щелкните, чтобы просмотреть изображение с полным размером)
Шаг 3. Добавление проверки на уровне полей в классы DataRow
Проверка на уровне полей — это проверки, относящиеся к значениям свойств бизнес-объектов при вставке или обновлении. Некоторые правила проверки на уровне полей для продуктов включают:
- Длина поля ProductName не должна превышать 40 символов.
- Длина поля QuantityPerUnit не должна превышать 20 символов
- Поля ProductID , ProductName и Discontinued являются обязательными, но все остальные поля являются необязательными.
- Поля UnitPrice , UnitsInStock , UnitsOnOrder и ReorderLevel должны быть больше или равны нулю
Эти правила можно и выражать на уровне базы данных. Ограничение на количество символов в полях ProductName и QuantityPerUnit захватывается типами данных этих столбцов в Products таблице ( nvarchar(40) и nvarchar(20) соответственно). Указывает, являются ли поля обязательными и необязательными, выражаются, если столбец таблицы базы данных допускает NULL s. Существуют четыре проверочных ограничения , которые гарантируют, что только значения, которые больше или равны нулю, могут быть в столбцах UnitPrice , UnitsInStock , UnitsOnOrder или ReorderLevel .
Помимо применения этих правил к базе данных, они также должны быть принудительно применены на уровне набора данных. На самом деле, длина поля и то, является ли значение обязательным или необязательным, уже захвачено для каждого набора столбцов DataTable. Чтобы просмотреть существующую проверку на уровне полей, перейдите в конструктор наборов данных, выберите поле из одной из таблиц DataTable, а затем перейдите к окно свойств. Как показано на рис. 4, QuantityPerUnit столбец данных в ProductsDataTable имеет максимальную длину 20 символов и допускает значения NULL . Если при попытке задать для свойства QuantityPerUnit ProductsDataRow строковое значение длиннее 20 символов, будет выдано ArgumentException .
Рис. 4. параметр DataColumn обеспечивает базовую проверку на уровне полей (щелкните, чтобы просмотреть изображение с полным размером)
К сожалению, невозможно указать проверки границ, например значение UnitPrice должно быть больше или равно нулю через окно свойств. Чтобы обеспечить такой тип проверки на уровне полей, необходимо создать обработчик событий для события ColumnChanging DataTable. Как упоминалось в предыдущем руководстве, объекты DataSet, DataTables и DataRow, созданные типизированным набором данных, можно расширить с помощью разделяемых классов. Используя этот прием, можно создать обработчик событий ColumnChanging для класса ProductsDataTable . Начните с создания класса в папке App_Code с именем ProductsDataTable.ColumnChanging.cs .
Рис. 5. Добавление нового класса в папку App_Code (щелкните, чтобы просмотреть изображение с полным размером)
Затем создайте обработчик событий для события ColumnChanging , которое гарантирует, что значения столбцов UnitPrice , UnitsInStock , UnitsOnOrder и ReorderLevel (если не NULL ) больше или равны нулю. Если какой-либо из этих столбцов выходит за пределы диапазона, вызовите ArgumentException .
Шаг 4. Добавление настраиваемых бизнес-правил в классы BLL
Помимо проверки на уровне полей, могут существовать настраиваемые бизнес-правила высокого уровня, использующие различные сущности или понятия, не вычисляемые на уровне одного столбца, например:
- Если продукт прекращен, его UnitPrice невозможно обновить
- Страна проживания сотрудника должна совпадать со страной проживания своего руководителя
- Невозможно прекратить работу продукта, если он является единственным продуктом, предоставленным поставщиком
Классы BLL должны содержать проверки, гарантирующие соблюдение бизнес-правил приложения. Эти проверки можно добавить непосредственно в методы, к которым они применяются.
Представьте, что наши бизнес-правила определяют, что продукт не может быть помечен как неподдерживаемый, если он был единственным продуктом от данного поставщика. То есть, если продукт x был единственным продуктом, приобретенным у поставщика Y, мы не можем помечать X как снятое. Однако если бы поставщик Y представил нам три продукта: A, Bи C, можно пометить все и все эти данные как снятые. Нерегулярное бизнес-правило, но бизнес-правила и распространенный смысл не всегда согласованы!
Чтобы применить это бизнес-правило в UpdateProducts методе, мы начнем с того, что для Discontinued было установлено значение true и, если да, мы вызываем GetProductsBySupplierID , чтобы определить, сколько продуктов было приобретено у этого поставщика продукта. Если у этого поставщика приобретен только один продукт, мы выдаем ApplicationException .
Реагирование на ошибки проверки на уровне представления
Как мы увидим в следующих учебных курсах, обработка исключений, которые поднимаются от BLL при использовании веб-элемента управления данными для вставки, обновления или удаления данных, может обрабатываться непосредственно в обработчике событий, в отличие от необходимости заключения кода в блоки try. catch .
Сводка
Хорошо спроектированное приложение создается на различных уровнях, каждый из которых инкапсулирует определенную роль. В первом учебнике этой серии статей мы создали уровень доступа к данным с помощью типизированных наборов данных. в этом учебнике мы создали уровень бизнес-логики в виде серии классов в папке App_Code приложения, которая вызывает DAL. В BLL для нашего приложения реализуется логика на уровне полей и бизнес-уровня. Помимо создания отдельного слоя BLL, как мы делали в этом учебнике, другой вариант — расширить методы TableAdapter с помощью разделяемых классов. Однако использование этой методики не позволяет переопределять существующие методы и не разделять DAL и BLL в соответствии с подходом, который мы сделали в этой статье.
Теперь, когда DAL и BLL завершены, мы готовы начать работу на нашем уровне представления. В следующем учебном курсе мы предоставим краткий обзор разделов, посвященных доступу к данным, и определим единообразный макет страницы для использования в рамках руководства.
Читайте также: