Яке використання має бізнес-логічний шар (BLL)?

Читаючи добру практику для застосувань баз даних, я часто натрапляю на прихильників так званих "шарів ділової логіки", і я намагаюся вирішити, чи краще для мого проекту використовувати один (це невеликий особистий проект). Моя проблема полягає в тому, що я не можу придумати що-небудь, щоб зробити BLL тим, що DAL вже не може обробити (виконання запитів і відображення результатів для об'єктів), тому мій BLL просто викликає DAL, нічого не роблячи сам.

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

Для менших додатків мій BLL зазвичай починається як перехід до DAL. Я з цим все гаразд. Коли я "відкриваю" правила ведення бізнесу, BLL - це те, де я їх розміщую. Я також знаходжу багато речей, необхідних в BLL, коли пишу свої тести. Для своїх особистих програм я складаю ділові правила, і BLL все ще там, де я їх розміщую. Для мене БЛЛ - це те, що зростає з часом. Чим довше я працював над проектом, тим більший його BLL.

Я б розглядав можливість поєднання BLL та DAL для невеликого проекту? Я можу, за винятком того, що я змінюю технології DAL приблизно так само часто, як змінюю зачіски, і мені подобається щось ізолювати мій клієнтський код від цього.

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

Андрій,

Шари бізнес-логіки - це те, що ви закінчуєте, коли займаєтеся розробкою, орієнтованою на домен, і зосереджуєтесь на основних заходах домену. Якщо ви зніміть презентаційний шар (gui, web) та інфраструктурний шар (db, підключення до мережі тощо), ви отримаєте основні акти, які є частиною вашого домену, наприклад, перерахування грошей на банківський рахунок. Тепер, якщо ви змоделювали свій бізнес-шар і виділили його з презентації та інфраструктури, ви можете легко перенести його на інші види використання, наприклад, на Інтернет або мобільні пристрої. Це чистий спосіб думати про розвиток, і з того, що я бачив, це, на жаль, не сприймається все так серйозно.

Я рекомендую взяти на себе руки Еріка Еванса - дизайну, керованого доменом, який є хорошою книгою, яка виправдовує зосередження зусиль на розробці домену. Щоправда, це трохи сухе прочитання на півдорозі, але воно набирає обертів і має певні переконання щодо того, що розробники роблять не так у сучасних системах.

Немає нічого, що говорить про те, що ВАМ БУТИ мати певну кількість ярусів або шарів. Все залежить від складності вашого проекту. Погляньте на багато зразків додатків MVC, таких як вечеря з ботаніком або магазин звукозаписів. Всі вони використовують 2 шари, тому що для програм, що мають дуже мало логіки обробки, це просто не має сенсу.

Однак, навіть якщо ваш додаток невеликий, це може отримати користь від абстрагування рівня даних від шару презентації через третій рівень, який, як правило, є бізнес-рівнем. Це дозволяє вносити зміни в одному місці, а не в усьому шарі презентації.

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

Якщо ви розумієте MVC, тобто .. Model View Controller, ви можете продумати архітектуру додатків аналогічно. Модель є аналогічною вашому шару даних, шаром презентації є Вид, а бізнес-шар - контролером.

Доповнення відповіді запустілої планети про дизайн, керований доменом:

Ознайомтеся також з архітектурою Onion , яка дуже відповідає концепціям дизайну, керованого доменом.

Зверніть увагу, як бізнес-логіка "Шар" є ядром лука, і кожен інфраструктурний рівень (наприклад, рівень доступу до даних) є його зовнішніми залежностями. Це дуже допомагає протестувати, оскільки ви повинні мати змогу знущатися над кожною залежністю від зовнішньої інфраструктури та повністю перевіряти логіку домену.

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

Однак деяким додаткам може не знадобитися така архітектура. Якщо всі ваші програми є CRUD-операціями з набором даних, то ваше «чисте концептуальне рішення» може бути фактично порожнім, і все, що вам потрібно, - це редагування бази даних фронтального типу. У такому випадку вам, мабуть, слід краще зосередитись лише на шарах DAL та UI.

Відповідь на це питання (IMHO): "чи можу я повністю замінити свій DAL і не доведеться переписувати будь-який мій бізнес-логічний код"?

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