BLL е бизнес логическият слой
DAL е слой за достъп до данни
Тристепенна архитектура на ASP.NET (DAL, BLL, UI)
Графиката представлява трислойна структура. Уебът е USL слой
уеб –> bll –> dal
| | |
| V |
+–> модел <—+
1. Тристепенна архитектура
1. Presentation layer (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 проект за уеб приложение, наименете го на потребителския интерфейс и създайте нов 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, и след като UI (в този случай е User.aspx.cs) извика BLL, за да получи UserInfo, той е обвързан с контрола на данните на User.aspx чрез код, за да се реализира показването на списъка. В този процес User.aspx.cs не играе роля в потребителския интерфейс, а се използва само за предаване на данни, и тъй като повечето от реалното кодиране е реализирано по този начин, някои хора смятат, че User.aspx.cs не трябва да се брои като потребителски интерфейс, а трябва да се слее с BLL за логическа обработка. По-нататък беше въведено ново изискване да се добави икона пред всеки потребител, която ярко да представя пола му, а за тези под 18 години тя се представяше с детска икона. Реализирането на това изискване е ред на User.aspx.cs и в този случай User.aspx.cs има реална употреба.
2、NewBLL.cs
Добавете следните методи:
публичен IList GetUsers(): Връща списък с цялата потребителска информация
public UserInfo GetUser(int UserId): Връща данните за посочения потребител
public 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(User);
return (userInfo.Id != null);
}
Тогава DAL не е необходимо да имплементира метода IsExist() и има логически процесорен код в BLL.
3、UserModel.cs
Същност, това нещо, може да мислиш, че не е лесно да се стратификацира. Включително и аз, го разбрах така: UI?àModel?àBLL?àModel?àDAL, така че се смята, че Моделът действа като мост за предаване на данни между слоевете. Но тук не мислим за нещата просто, а за сложността.
Какво е модел? Това е нищо! Тя е заменима в тристепенна архитектура. Всъщност това е най-базовото нещо в обектно-ориентираното програмиране: класовете. Таблицата е клас, новините също са клас, int, string, dublie и т.н. също са класове, това е просто клас.
По този начин позицията на модела в трислойната архитектура е същата като статуса на променливи като int и низ, и няма друга цел, използва се само за съхранение на данни, но съхранява сложни данни. Следователно, ако обектите във вашия проект са много прости, можете директно да предавате множество параметри без модел, за да създадете трислойна архитектура.
Защо тогава ви е нужен модел и какви са неговите предимства? Следното е какво ви идва наум, когато мислите за въпрос, вмъкнат тук:
Може ли Моделът да играе по-голяма роля в предаването на параметрите на всеки слой?
Когато предавате параметри между слоевете, можете да направите следното:
AddUser(userId, потребителско име, потребителска парола,...,)
Може да бъде и така:
AddUser(userInfo)
Кой от тези два метода е по-добър? На пръв поглед трябва да е вторият много по-добър.
Кога да предавам параметри между слоеве с нормални типове променливи (int, string, guid, double) и какво да предавам с Model? Следните методи:
SelectUser(int UserId)
SelectUserByName (потребителско име на низ)
SelectUserByName(потребителско име на низ, парола за низ)
SelectUserByEmail (низов имейл)
SelectUserByEmail (низ имейл, парола за низ)
То може да се обобщи така:
SelectUser(userId)
SelectUser(потребител)
Тук използваме обекта user model, за да включим четири комбинации от потребителско име, парола и имейл. UserId също може да се слее с user, но други BLL в проекта имплементират интерфейси с id параметри, така че и този елемент се запазва.
userInfo е предаден, така че как да се справим с това? Това трябва да е в реда, има конкретен код за решаване.
Тук се обработва в този ред
Първо провери дали имаш и потребителско име, и парола, после дали имаш и имейл, и парола, после дали имаш потребителско име и после дали имаш имейл. Обработен последователно.
По този начин, ако в бъдеще се добави ново съдържание, членската карта (номер), няма нужда да се променя интерфейсът, просто се добавя поддръжка за номер в DAL кода и след това се добавя производителността и обработката на съдържанието на членската карта на преден план.
4、UserDAL.cs
public IList SelectUsers(): Връща списък с цялата потребителска информация
public UserInfo SelectUser(int UserId): Връща доверената информация на посочения потребител
публичен bool InsertUser(UserInfo User): Добавена информация за потребителя
public bool UpdateUser(UserInfo User): Актуализира потребителската информация
public void DeleteUser(int UserId): Премахва потребителска информация
Това, което много хора не могат да разберат най-много, е слоят за достъп до данни, коя част се счита за слой за достъп до данни? Някои хора мислят, че базата данни е слоят за достъп до данни, което не е ясно относно дефиницията, DAL е слоят за достъп до данни, а не слоят за съхранение на данни, така че базата данни не може да бъде този слой. Ролята на SQLHelper е да намали повтарящото се кодиране и да подобри ефективността на програмирането, така че ако съм свикнал да се интересувам от ефективността или да използвам източник на данни, който не е от база данни, мога да изхвърля SQLHelper, част, която може да бъде изхвърлена по желание, как може да се превърне в слой от трислойната архитектура.
Той може да бъде дефиниран по следния начин: кодът, свързан с операции с източник на данни, трябва да бъде поставен в слоя за достъп до данни, който принадлежи към слоя за достъп до данни
5、IUserDAL
Интерфейс за слоя за достъп до данни, това е още едно излишно нещо, защото Petshop го носи заедно с ClassFactory Factory, така че някои проекти правят тези две неща, независимо дали трябва да поддържат няколко източника на данни или не, а някои дори не изграждат 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, без да се изискват други операции и т.н. Първоначално исках да добавя конкретен код към статията, но не смятам, че е необходимо, ако смятате за необходимо, ще го добавя.
Резюме: Не мислете, че един слой е ненужен само защото е безполезен за вас, или е особено лесен за внедряване, изоставяне или използване за други цели. Докато слоевете се изпълняват, независимо колко слоеве има, всеки слой трябва да има ясна цел и реализиране на функцията и не трябва да бъде повлиян от самия процес, което води до разположение на един и същ тип файл в различни слоеве. Не позволявайте един и същ слой да имплементира различни функции. |
Публикувано в 7.05.2015 г. 10:53:35 ч.
|
|
|
