BLL — це бізнес-логічний шар
DAL — це рівень доступу до даних
Трирівнева архітектура ASP.NET (DAL, BLL, UI)
Графіка є тришаровою структурою. Веб — це рівень USL
web –> bll –> dal
| | |
| V |
+–> модель <—+
1. Трирівнева архітектура
1. Рівень презентації (USL): Він переважно представляє метод WEB, але також може бути виражений у режимі WINFORM. Якщо логічний шар досить надійний і добре усталений, він ідеально працюватиме незалежно від того, як рівень продуктивності визначений і змінений.
2. Шар бізнес-логіки (BLL): переважно для конкретних задач його також можна розуміти як роботу рівня даних і логічну обробку бізнесу даних. Якщо рівень даних — це будівельні блоки, то логічний шар — це будівельний блок.
3. Шар доступу до даних (DAL): Це переважно операційний шар оригінальних даних (у вигляді бази даних, текстового файлу або іншої форми зберігання даних), а не оригінальних даних, тобто роботи даних, а не бази даних, зокрема шару бізнес-логіки чи презентації
Надання послуг з обробки даних.
2. Специфічне розрізнення
1. Рівень презентації: головним чином приймає запит користувача та повертає дані, надаючи клієнту доступ до додатку.
2. Шар бізнес-логіки: головним чином відповідає за роботу шару даних, тобто за поєднання деяких операцій на цьому рівні.
3. Шар доступу до даних: Він головним чином залежить від того, чи містить ваш рівень даних логічну обробку; насправді його функції здебільшого виконують різні операції над файлом даних і не турбуються про інші операції.
3. Короткий зміст
Структура з трьох рівнів є суворо ієрархічним підходом, тобто до рівня доступу до даних (DAL) можна отримати лише рівень бізнес-логіки (BLL), а до шару бізнес-логіки — лише рівень презентації (USL). Деякі тришарові структури також додають інші шари, такі як Factory і Model, які фактично є розширенням і застосуванням на основі цих трьох шарів.
Проста тришарова програма зазвичай включає кілька проєктів моделі DAL BLL, і їхні взаємні посилання такі:
1) WEB посилання на BLL, модель
2) BLL посилається на DAL, модель
3) Модель посилань на DAL
4) Модель не має посилань
Коли йдеться про трирівневу архітектуру, всі знають, що це рівень продуктивності (UI), бізнес-логічний рівень (BLL) і рівень доступу до даних (DAL), і існує багато способів поділити кожен шар. Але як писати конкретний код і на якому рівні ці файли враховуються — незрозуміло. Нижче наведено простий приклад, який допоможе вам попрактикуватися у тришаровому архітектурному проєкті, цей приклад має лише одну функцію — просте управління користувачами.
Спочатку створіть порожнє рішення і додайте наступні елементи та файли
1. Додайте ASP.NET проєкт веб-додатку, назвіть його UI та створіть новий User.aspx файлу веб-форми (включаючи User.aspx.cs)
2. Додайте проєкт ClassLibrary, назвіть його BLL і створіть новий файл Class UserBLL.cs
3. Додайте проєкт ClassLibrary, назвіть його DAL і створіть новий файл Class UserDAL.cs. Додайте посилання на SQLHelper. (Це курс Microsoft з доступу до даних, або ви можете написати весь код доступу до даних безпосередньо.) Зазвичай я використовую клас DataAccessHelper, який пишу).
4. Додайте проєкт ClassLibrary, назвіть його Model і створіть новий файл типу Class UserModel.cs
5. Додайте проєкт ClassLibrary, назвіть його IDAL і створіть новий інтерфейсний файл IUserDAL.cs
6. Додайте проєкт ClassLibrary і назвіть його ClassFactory
Я вважаю, ви бачили, що це нічим не відрізняється від прикладу Petshop, і це простіше, бо я також вивчаю тришарову архітектуру через Petshop. Однак деякі друзі можуть бути нечіткими щодо рівня цих проєктів і їхніх стосунків, ось пояснення їх по черзі:
1. User.aspx і User.aspx.cs
Обидва документи (і елементи, до яких належить файл, а також нижче, не будуть повторюватися) є частиною рівня презентації. User.aspx легше зрозуміти, бо це відображена сторінка. User.aspx.cs деякі вважають, що його не слід враховувати, а слід включати до шару бізнес-логіки. Якщо ви не займаєтеся шаруванням, то немає проблем дозволити User.aspx.cs керувати бізнес-логікою і навіть керувати базою даних, але якщо ви займаєтеся шаруванням, цього робити не варто. У ієрархічній структурі User.aspx.cs має стосуватися лише контенту, пов'язаного з відображенням, і нічого іншого не слід охоплювати.
Наприклад, якщо ми реалізуємо функцію відображення користувачів у вигляді списку, то роботу з вилучення інформації виконує BLL, і після того, як інтерфейс (у цьому випадку це User.aspx.cs) викликає BLL для отримання UserInfo, він прив'язується до керування даними User.aspx через код, щоб реалізувати відображення списку. У цьому процесі, User.aspx.cs він не відіграє ролі в інтерфейсі, він використовується лише для передачі даних, і оскільки більшість фактичного кодування реалізовано саме так, деякі вважають, що User.aspx.cs не слід вважати UI, а слід об'єднувати з BLL для логічної обробки. Далі було запропоновано нову вимогу додати іконку перед кожним користувачем для яскравого відображення статі користувача, а для тих, кому менше 18 років, вона була представлена дочірньою іконкою. Реалізація цієї вимоги — це поворот User.aspx.cs, і в цьому випадку User.aspx.cs вона має реальне застосування.
2、NewBLL.cs
Додайте такі методи:
публічний IList GetUsers(): Повертає список усієї інформації про користувача
публічний UserInfo GetUser(int UserId): Повертає дані вказаного користувача
публічний bool AddUser(UserInfo User): Додано інформацію про користувача
публічний bool ChangeUser(UserInfo User): Оновлює інформацію про користувачів
public void RemoveUser(int UserId): Видаляє інформацію про користувача
Цей файл належить до шару бізнес-логіки і призначений для обробки операцій, пов'язаних із бізнес-логікою. Багато хто може вважати, що єдине призначення цього шару — це пересилання даних з рівня продуктивності на рівень даних. Справді, таких випадків багато, але це може означати лише те, що проєкт відносно простий або що взаємозв'язок між самим проєктом і бізнесом не є тісно інтегрованим (як, наприклад, нинішній популярний MIS), тому бізнес-шар не має жодних справ і лише виконує роль пересилання. Але це не означає, що бізнес-шар є зайвим: коли проєкт зростає або з'являється більше ділових відносин, бізнес-рівень відображатиме його роль.
Найімовірніша помилка тут полягає у призначенні коду операцій даних на бізнес-логічний шар, а базу даних — на рівень доступу до даних.
Наприклад, деякі друзі вважають, що рівень BLL не має значення, але вони просто завантажують дані DAL і пересилають їх у інтерфейс без жодної обробки. Погляньте на цей приклад
Шар BLL
SelectUser (UserInfo userInfo) отримує дані користувача на основі імені користувача або електронної пошти, яка приходить.
IsExist (UserInfo userInfo) визначає, чи існує вказане ім'я користувача або електронна пошта.
Тоді DAL також надає відповідний метод для виклику BLL
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Таким чином, BLL виконує лише роль передачі.
Але якщо ви це зробите:
Блін. IsExist(Userinfo userinfo)
{
UerInfo користувач = DAL. SelectUser(Користувач);
return (userInfo.Id != null);
}
Тоді DAL не потрібно реалізовувати метод IsExist(), і в BLL є логічний код обробки.
3、UserModel.cs
Сутність, ти можеш думати, що це важко стратифікувати. Включно зі мною, я розумів це так: UI?àModel?àBLL?àModel?àDAL, тому вважається, що Модель виступає мостом для передачі даних між шарами. Але тут ми не думаємо про прості речі, а про складність.
Що таке Model? Це нічого! Він є замінним у трирівневій архітектурі. Насправді це найпростіша річ у об'єктно-орієнтованому програмуванні: класи. Таблиця — це клас, новини — це також клас, інтелект, рядок, дублі тощо — це теж класи, це просто клас.
Таким чином, позиція моделі в тришаровій архітектурі збігається зі статусом змінних, таких як int і string, і не має іншої мети, вона використовується лише для зберігання даних, але зберігає складні дані. Тому, якщо об'єкти у вашому проєкті дуже прості, ви можете безпосередньо передавати кілька параметрів без моделі, щоб створити тришарову архітектуру.
То навіщо вам потрібна модель і які її переваги? Ось що спадає на думку, коли думаєш про питання, вставлене тут:
Чи може Модель відігравати більшу роль у передачі параметрів на кожному рівні?
При передачі параметрів між шарами можна зробити наступне:
AddUser(userId,userName,userPassword,...,)
Це також може бути так:
AddUser(userInfo)
Який із цих двох методів кращий? На перший погляд, це, мабуть, другий набагато кращий.
Коли передавати параметри між шарами з нормальними типами змінних (int, string, guid, double) і що передавати у Model? Наступні методи:
SelectUser(int UserId)
SelectUserByName (ім'я користувача рядка)
SelectUserByName (ім'я користувача рядка, пароль від рядка)
SelectUserByEmail (рядковий лист)
SelectUserByEmail (рядковий лист, пароль від рядка)
Його можна підсумувати так:
SelectUser(userId)
SelectUser(користувач)
Тут ми використовуємо об'єкт моделі користувача для включення чотирьох комбінованих режимів: ім'я користувача, пароль і електронна пошта. UserId також можна об'єднати з user, але інші BLL у проєкті реалізують інтерфейси з параметрами id, тому цей елемент також зберігається.
userInfo передається, тож як з цим впоратися, це має бути в порядку, є конкретний код, який потрібно вирішити.
Тут усе обробляється в такому порядку
Спочатку перевірте, чи є у вас і ім'я користувача, і пароль, потім чи є і email, і пароль, потім чи є у вас ім'я користувача, а потім перевірте, чи є у вас електронна пошта. Обробляється послідовно.
Таким чином, якщо в майбутньому додається новий контент — членську картку (номер), немає потреби змінювати інтерфейс, достатньо додати підтримку номера в коді DAL, а потім додати продуктивність і обробку вмісту членської картки на передньому плані.
4、UserDAL.cs
публічний IList SelectUsers(): Повертає список усієї інформації про користувача
public UserInfo SelectUser(int UserId): Повертає довірену інформацію вказаного користувача
public bool InsertUser(UserInfo User): Додано інформацію про користувача
публічний bool UpdateUser(UserInfo User): Оновлення інформації користувачів
public void DeleteUser(int UserId): Видаляє інформацію про користувача
Що багато людей не можуть зрозуміти найбільше — це рівень доступу до даних, яка частина вважається рівнем доступу до даних? Дехто вважає, що база даних — це рівень доступу до даних, що не зовсім зрозуміло щодо визначення, DAL — це рівень доступу до даних, а не рівень зберігання даних, тому база даних не може бути саме цим рівнем. Роль SQLHelper полягає у зменшенні повторюваного кодування та підвищенні ефективності кодування, тож якщо я звик дбати про ефективність або використовувати джерело даних, не пов'язане з базою даних, я можу відмовитися від SQLHelper — частини, яку можна відкинути за бажанням, як вона може стати шаром тришарової архітектури?
Його можна визначити так: код, пов'язаний з операціями з джерелом даних, слід розміщувати на рівні доступу до даних, який належить до рівня доступу до даних
5、IUserDAL
Інтерфейс рівня доступу до даних — це ще одна зайва річ, бо Petshop приносить його разом із ClassFactory і ClassFactory, тому деякі проєкти роблять ці дві речі незалежно від того, чи потрібно їм підтримувати кілька джерел даних, а деякі навіть не створюють ClassFactory, а лише збирають IDAL, і тоді "IUserDAL iUserDal = новий UserDAL(); Я не знаю, що це означає. Це повністю тигр, а не антисобака.
Багато людей тут мають хибне уявлення, що існує такий зв'язок: BLL?àIDAL?àDAL, вважаючи, що IDAL є мостом між BLL і DAL, а BLL називає DAL через IDAL. Але реальність така, що навіть якщо записати це так: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Під час виконання "iUserDal.SelectUsers()" фактично виконується інстанція UserDAL, а не інстанція IUserDAL, тому позиція IDAL на третьому рівні пов'язана з рівнем DAL.
У наведеному вище вступі ієрархія трирівневої архітектури в основному пояснюється. Насправді я маю спосіб оцінити, чи є тришарова архітектура стандартною, тобто повна заміна будь-якого з трьох рівнів не вплине на інші два, і така структура фактично відповідає тришаровому стандарту (хоча реалізувати її складніше ^_^). Наприклад, якщо ви змінюєте проєкт з B/S на C/S (або навпаки), тоді BLL і DAL не потрібно змінювати, окрім інтерфейсу; Або змінити SQLServer на Oracle, просто замінити SQLServerDAL на OracleDAL, інших операцій не потрібно тощо. Спочатку я хотів додати певний код до статті, але не вважаю це необхідним, якщо ви вважаєте це необхідним — я додам його.
Підсумок: Не думайте, що шар зайвий лише тому, що він вам марний, або що його особливо легко реалізувати, відмовитися чи використати для інших цілей. Поки шари виконані, незалежно від кількості шарів, кожен шар має чітко визначену мету та функцію, і не повинен впливати на сам процес, через що один і той самий тип файлів розташовується в різних шарах. Не дозволяйте одному шару реалізовувати різні функції. |
Опубліковано 07.05.2015 10:53:35
|
|
|
