Для чего нужен уровень бизнес-логики (BLL)?

Читая о хорошей практике для приложений баз данных, я часто встречал сторонников так называемых «уровней бизнес-логики», и я пытаюсь решить, лучше ли для моего проекта использовать один (это небольшой личный проект). Моя проблема заключается в том, что я не могу придумать для BLL ничего такого, что DAL уже не может обработать (выполнение запросов и сопоставление результатов с объектами), поэтому мой BLL просто вызывает DAL, ничего не делая сам.

Может быть, я ошибаюсь в том, что именно DAL должен делать тоже. Но независимо от того, какой функциональности следует ожидать от BLL в приложении для управления базами данных?

Для моих небольших приложений мой BLL обычно начинается как переход к DAL. Я в порядке с этим. Когда я «открываю» бизнес-правила, я ставлю их в BLL. Я также заканчиваю тем, что нашел много вещей, необходимых в BLL, когда я пишу свои тесты. Для своих личных приложений я составляю бизнес-правила, а BLL все еще там, где я их ставлю. Для меня BLL - это то, что растет со временем. Чем дольше я работаю над проектом, тем больше его BLL.

Буду ли я рассматривать объединение BLL и DAL для небольшого проекта? Я мог бы, за исключением того факта, что я меняю технологии DAL примерно так же часто, как меняю прически, и мне нравится иметь что-то, что изолирует мой клиентский код от этого.

BLL будет обрабатывать вещи, которые являются частью бизнес-сферы, а не частью базы данных и не частью пользовательского интерфейса (обычно). Например, используя возраст клиента, чтобы определить, имеют ли он право на специальную скидку для пожилых людей. DAL не должен этого делать, он должен просто извлекать данные о клиентах, а затем сохранять их с данными о скидках после того, как BLL выполнит свою работу. DAL должен сосредоточиться больше на CRUD. В небольших приложениях эти две проблемы могут пересекаться.

Андрей,

Слои бизнес-логики - это то, с чем вы сталкиваетесь, когда занимаетесь разработкой, управляемой доменом, и сосредотачиваетесь на основных видах деятельности домена. Если вы удалите уровень представления (gui, web) и инфраструктурный уровень (db, сетевое подключение и т. Д.), Вы получите основные виды деятельности, которые являются частью вашего домена, например, внесение денег на банковский счет. Теперь, если вы смоделировали свой бизнес-уровень и изолировали его от презентации и инфраструктуры, вы можете легко перенести его на другое использование, например, на веб-сайты или мобильные устройства. Это чистый способ думать о разработке, и из того, что я видел, к сожалению, не все воспринимают всерьез.

Я бы порекомендовал Эрику Эвансу - Domain Driven Design, который является хорошей книгой, которая оправдывает сосредоточение усилий на разработке на домене. По общему признанию, это немного сухое чтение на полпути, но оно действительно набирает обороты и имеет некоторые твердые убеждения относительно того, что разработчики делают неправильно с сегодняшними системами.

Там нет ничего, что говорит, что вы должны иметь определенное количество уровней или слоев. Все зависит от сложности вашего проекта. Взгляните на многие примеры приложений MVC, такие как обед или магазин звукозаписей. Все они используют 2 уровня, потому что для приложений, которые имеют очень мало логики обработки, это просто не имеет смысла.

Однако даже если ваше приложение маленькое, оно может извлечь выгоду из абстрагирования уровня данных от уровня представления через третий уровень, который обычно является бизнес-уровнем. Это позволяет вам вносить изменения в одном месте, а не на всем уровне представления.

Предположим, вы решили изменить свой ORM с Linq на SQL на Entity Framework (или nhibernate). Вероятно, будет легче изменить его на бизнес-уровне, чем на уровне презентации, поскольку презентация тесно связана с его моделью презентации.

Если вы понимаете MVC, то есть .. Model View Controller, вы можете думать об архитектуре вашего приложения в аналогичных терминах. Модель аналогична вашему уровню данных, уровень презентации - это представление, а бизнес-уровень - это контроллер.

Дополняя ответ Desolate Planet о доменно-управляемом дизайне:

Посмотрите также на Onion Architecture , которая очень соответствует концепциям, управляемым доменом.

Обратите внимание, что «Уровень» бизнес-логики является ядром лука, а каждый уровень инфраструктуры (например, уровень доступа к данным) является его внешними зависимостями. Это очень помогает в тестировании, потому что вы должны быть в состоянии смоделировать каждую зависимость от внешней инфраструктуры и полностью протестировать логику вашего домена.

На мой взгляд: уровень бизнес-логики - это то, где живет «чистое концептуальное решение». Остальные - это просто детали реализации инфраструктуры.

Однако некоторым приложениям может не понадобиться такая архитектура. Если все ваши приложения являются операциями CRUD с наборами данных, ваше «чисто концептуальное решение» может фактически быть практически пустым, и все, что вам нужно, - это интерфейс редактирования базы данных. В этом случае вам, вероятно, лучше сосредоточиться только на слоях DAL и UI.

Ответ на этот вопрос (ИМХО): «Могу ли я полностью заменить свой DAL и не нужно переписывать какой-либо код моей бизнес-логики»?

Думайте об этом как о своем уровне представления - довольно распространено думать об изменении графического интерфейса на другой, толстый графический интерфейс рабочего стола заменяется на веб-клиент, который заменяется на приложение для iPhone. Для BLL / DAL это не так часто думать, так как они никогда не меняются местами, за исключением, может быть, чего-то очень похожего (например, БД SQLServer заменяется на MySQL), но если вы предполагаете, что вам нужно было изменить вашу БД на распределенное хранилище Сервис, к которому обращались с помощью API, вы можете получить более четкое представление о том, где слои встречаются.