BLL este Stratul de Logică de Afaceri
DAL este stratul de acces la date
Arhitectura în trei niveluri a ASP.NET (DAL, BLL, UI)
Grafica reprezintă o structură în trei straturi. Web-ul este stratul USL
web –> bll –> dal
| | |
| V |
+–> model <—+
1. Arhitectură pe trei niveluri
1. Stratul de prezentare (USL): Reprezintă în principal metoda WEB, dar poate fi exprimat și ca mod WINFORMS. Dacă stratul logic este destul de robust și bine stabilit, va funcționa perfect indiferent cum este definit și modificat stratul de performanță.
2. Stratul logicii de afaceri (BLL): în principal pentru probleme specifice, poate fi înțeles și ca operarea stratului de date și procesarea logică a afacerii de date. Dacă stratul de date este blocul de construcție, atunci stratul logic este blocul de construcție.
3. Stratul de acces la date (DAL): Este în principal stratul operațional al datelor originale (sub forma unei baze de date sau a unui fișier text sau a altor forme de stocare a datelor), mai degrabă decât datele originale, adică operarea datelor, nu baza de date, în special stratul logicii de afaceri sau stratul de prezentare
Furnizarea serviciilor de date.
2. Distincție specifică
1. Stratul de prezentare: acceptă în principal cererea utilizatorului și returnează date, oferind clientului acces la aplicație.
2. Stratul logicii de business: responsabil în principal pentru funcționarea stratului de date, adică combinarea unor operațiuni pe stratul de date.
3. Stratul de acces la date: Depinde în principal dacă stratul tău de date conține procesare logică; de fapt, funcțiile sale completează în principal diverse operații asupra fișierului de date și nu trebuie să te îngrijorezi de alte operații.
3. Rezumat
Structura pe trei straturi este o abordare strict ierarhică, adică stratul de acces la date (DAL) poate fi accesat doar de stratul de logică de afaceri (BLL), iar stratul de logică de afaceri poate fi accesat doar de stratul de prezentare (USL). Unele structuri cu trei straturi adaugă și alte straturi, cum ar fi Factory și Model, care sunt de fapt o extensie și o aplicație pe baza acestor trei straturi.
Un program simplu cu trei straturi include, în general, mai multe proiecte ale modelului web DAL BLL, iar referințele lor comune sunt următoarele
1) Referințe WEB BLL, Model
2) BLL face referire la DAL, Model
3) Referințe DAL Model
4) Modelul nu are citări
Când vine vorba de arhitectura cu trei niveluri, toată lumea știe că este vorba despre stratul de performanță (UI), stratul de logică de afaceri (BLL) și stratul de acces la date (DAL), iar există multe moduri de a subdiviza fiecare strat. Dar modul de a scrie codul specific și în ce strat sunt incluși acele fișiere este vag. Următorul este un exemplu simplu care te conduce să practici un proiect de arhitectură pe trei niveluri, acest exemplu are o singură funcție, și anume, gestionarea simplă a utilizatorilor.
Mai întâi, creează o soluție goală și adaugă următoarele elemente și fișiere
1. Adaugă un proiect ASP.NET aplicație web, numește-l UI și creează un nou fișier de formular web User.aspx (inclusiv User.aspx.cs)
2. Adaugă un proiect ClassLibrary, numește-l BLL și creează un nou fișier Class UserBLL.cs
3. Adaugă un proiect ClassLibrary, numește-l DAL și creează un nou fișier Class UserDAL.cs. Adaugă o referință SQLHelper. (Aceasta este clasa de acces la date a Microsoft, sau poți scrie tot codul de acces direct la date.) De obicei folosesc clasa DataAccessHelper pe care o scriu).
4. Adaugă un proiect ClassLibrary, numește-l Model și creează un nou fișier de tip Class UserModel.cs
5. Adaugă un proiect ClassLibrary, numește-l IDAL și creează un nou fișier Interface IUserDAL.cs
6. Adaugă un proiect ClassLibrary și numește-l ClassFactory
Cred că ai văzut că nu este diferit de exemplul de la Petshop și este mai simplu, pentru că învăț și arhitectura în trei straturi prin Petshop. Totuși, unii prieteni pot fi vagi în privința nivelului acestor proiecte și a relației dintre ele, iată o explicație a lor unul câte unul:
1. User.aspx și User.aspx.cs
Ambele documente (și elementele cărora aparține fișierul, precum și cele de mai jos, nu vor fi repetate) fac parte din stratul de prezentare. User.aspx este mai ușor de înțeles pentru că este o pagină de afișare. User.aspx.cs unii cred că nu ar trebui să fie luat în calcul, ci inclus în stratul logicii de business. Dacă nu faci stratificare, atunci nu există nicio problemă să User.aspx.cs lași să gestionezi logica de business și chiar să operezi baza de date, dar dacă faci stratificare, acest lucru nu ar trebui făcut. Într-o structură ierarhică, User.aspx.cs ar trebui să se ocupe doar de conținut legat de afișare, iar nimic altceva nu ar trebui acoperit.
De exemplu, dacă implementăm funcția de afișare a utilizatorilor sub forma unei liste, atunci munca de extragere a informațiilor este realizată de BLL, iar după ce UI-ul (în acest caz, este User.aspx.cs) apelează la BLL pentru a obține UserInfo, aceasta este legată de controlul datelor User.aspx prin cod pentru a realiza afișarea listei. În acest proces, User.aspx.cs nu joacă un rol în interfață, este folosit doar pentru a transmite date, iar pentru că majoritatea codării propriu-zise este implementată astfel, unii consideră că User.aspx.cs nu ar trebui să fie considerată UI, ci integrată în BLL pentru procesare logică. Privind mai departe, a fost propusă o nouă cerință de a adăuga o pictogramă în fața fiecărui utilizator care să reprezinte viu genul utilizatorului, iar pentru cei sub 18 ani, aceasta era reprezentată printr-o pictogramă copil. Realizarea acestei cerințe este rândul User.aspx.cs, iar în acest caz User.aspx.cs are o utilitate reală.
2、NewBLL.cs
Adaugă următoarele metode:
publicul IList GetUsers(): returnează o listă cu toate informațiile utilizatorilor
public UserInfo GetUser(int UserId): returnează detaliile utilizatorului specificat
public bool AddUser(UserInfo User): Informații adăugate de utilizator
public bool ChangeUser(UserInfoUser): Actualizează informațiile utilizatorilor
public void RemoveUser(int UserId): Elimină informațiile utilizatorului
Acest fișier aparține stratului de logică de afaceri și este dedicat manipulării operațiunilor legate de logica de afaceri. Mulți oameni pot crede că singura utilizare a acestui strat este de a transmite datele de la stratul de performanță la cel de date. Există într-adevăr multe astfel de cazuri, dar acest lucru poate însemna doar că proiectul este relativ simplu sau că relația dintre proiect în sine și afacere nu este strâns integrată (cum ar fi actualul MIS popular), astfel încât nivelul de afaceri nu are nimic de făcut și joacă doar un rol de forwarding. Dar asta nu înseamnă că stratul de business este de nerefuzat, pe măsură ce proiectul crește sau există mai multe relații de afaceri, stratul de business va reflecta rolul său.
Cea mai probabilă eroare aici este atribuirea codului operațiunii de date stratului de logică de business și bazei de date ca strat de acces la date.
De exemplu, unii prieteni simt că stratul BLL nu are sens, dar pur și simplu încarcă datele DAL și le trimit către UI fără procesare. Aruncă o privire la acest exemplu
Stratul BLL
SelectUser(UserInfo userInfo) obține detaliile utilizatorului pe baza numelui de utilizator sau a emailului care primește.
IsExist(UserInfo userInfo) determină dacă numele de utilizator sau emailul specificat există.
Apoi, DAL-ul oferă și metoda corespunzătoare pentru apelul BLL
SelectUser(UserInfoUserInfo)
IsExist(UserInfo userInfo)
În acest fel, BLL joacă doar un rol de transmisie.
Dar dacă da:
BLL. IsExist (Userinfo userinfo)
{
UerInfo user = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Atunci DAL nu trebuie să implementeze metoda IsExist(), iar în BLL există cod logic de procesare.
3、UserModel.cs
Entitate, chestia asta, poate crezi că nu este ușor de stratificat. Incluzându-mă și pe mine, am înțeles astfel: UI?àModel?àBLL?àModel?àDAL, deci se crede că Modelul acționează ca o punte pentru transmiterea datelor între straturi. Dar aici nu ne gândim la lucruri simple, ci la complexitate.
Ce este Modelul? Nu e nimic! Este dispensabil într-o arhitectură cu trei niveluri. De fapt, este cel mai de bază lucru în programarea orientată pe obiecte: clasele. Un tabel este o clasă, o știre este tot o clasă, int, string, doublie etc. sunt și ele clase, este doar o clasă.
Astfel, poziția modelului în arhitectura cu trei straturi este aceeași cu starea variabilelor precum int și string și nu are alt scop, fiind folosit doar pentru stocarea datelor, dar stochează date complexe. Prin urmare, dacă obiectele din proiectul tău sunt foarte simple, poți transmite direct mai mulți parametri fără un model pentru a crea o arhitectură în trei straturi.
Deci, de ce ai nevoie de un model și care sunt beneficiile sale? Următoarele sunt cele care îmi vin în minte când mă gândesc la o întrebare, inserat aici:
Poate modelul să joace un rol mai important în transmiterea parametrilor la fiecare strat?
Când treci parametri între straturi, poți face următoarele:
AddUser(userId,userName,userPassword,...,)
Poate fi și așa:
AddUser(userInfo)
Care dintre aceste două metode este mai bună? La prima vedere, trebuie să fie a doua variantă mult mai bună.
Când să treci parametrii între straturi cu tipuri normale de variabile (int, string, guid, double) și ce să treci cu Model? Următoarele metode:
SelectUser(int UserId)
SelectUserByName(string username)
SelectUserByName(string username, string password)
SelectUserByEmail(string email)
SelectUserByEmail (șir de email, șir de parolă)
Poate fi rezumat astfel:
SelectUser(userId)
SelectUser(user)
Aici folosim obiectul model de utilizator pentru a include patru moduri combinate: nume de utilizator, parolă și email. UserId poate fi de asemenea fuzionat cu utilizator, dar alte BLL din proiect implementează interfețe cu parametri de id, astfel încât acest element este păstrat.
userInfo se transmite, deci cum să gestionezi asta, trebuie să fie în ordinea ordinii, există un cod specific de decis.
Aici este procesat în această ordine
Mai întâi, verifică dacă ai atât numele de utilizator, cât și parola, apoi vezi dacă ai atât email, cât și parolă, apoi vezi dacă ai nume de utilizator și apoi vezi dacă ai email. Procesat secvențial.
Astfel, dacă în viitor se adaugă un conținut nou, cardul de membru (numărul), nu este nevoie să se schimbe interfața, doar să se adauge suport pentru numărul în codul DAL, apoi să se adauge performanța și procesarea conținutului cardului de membru în prim-plan.
4、UserDAL.cs
public IList SelectUsers(): returnează o listă cu toate informațiile utilizatorilor
public UserInfo SelectUser(int UserId): returnează informațiile de încredere ale utilizatorului specificat
public bool InsertUser(UserInfoUser): Informații adăugate de utilizator
public bool UpdateUser(UserInfo User): Actualizează informațiile utilizatorului
public void DeleteUser(int UserId): Elimină informațiile utilizatorului
Ceea ce mulți oameni nu reușesc să descifreze cel mai bine este stratul de acces la date, care parte este considerată stratul de acces la date? Unii oameni cred că baza de date este stratul de acces la date, ceea ce nu este clar în privința definiției, DAL este stratul de acces la date, nu stratul de stocare a datelor, deci baza de date nu poate fi acest nivel. Rolul SQLHelper este de a reduce codificarea repetitivă și de a îmbunătăți eficiența codării, așa că, dacă sunt obișnuit să mă preocup de eficiență sau să folosesc o sursă de date non-bază de date, pot renunța la SQLHelper, o parte care poate fi aruncată oricând, cum ar putea deveni un strat al arhitecturii cu trei straturi?
Poate fi definit astfel: codul legat de operațiunile sursei de date ar trebui plasat în stratul de acces la date, care aparține stratului de acces la date
5、IUserDAL
Interfața stratului de acces la date, acesta este un alt lucru de nefolosit, pentru că Petshop aduce cu ea și ClassFactory Factory, așa că unele proiecte fac aceste două lucruri indiferent dacă trebuie sau nu să suporte mai multe surse de date, iar unele chiar nu construiesc ClassFactory, ci doar IDAL, iar apoi "IUserDAL iUserDal = new UserDAL(); Nu știu ce înseamnă asta. Este complet un tigru și nu un anti-câine.
Mulți oameni au o concepție greșită aici, și anume că există o astfel de relație: BLL?àIDAL?àDAL, crezând că IDAL acționează ca o punte între BLL și DAL, iar BLL numește DAL prin IDAL. Dar realitatea este că, chiar dacă o programezi astfel: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Când se execută "iUserDal.SelectUsers()", de fapt instanța UserDAL este executată, nu instanța IUserDAL, astfel încât poziția IDAL în al treilea strat este legată de nivelul DAL.
Prin introducerea de mai sus, ierarhia arhitecturii în trei niveluri este explicată practic. De fapt, am o modalitate de a judeca dacă arhitectura cu trei straturi este standard, adică înlocuirea completă a oricăruia dintre cele trei straturi nu va afecta celelalte două straturi, iar o astfel de structură respectă practic standardul celor trei straturi (deși este mai dificil ^_^ de implementat). De exemplu, dacă schimbi proiectul de la B/S la C/S (sau invers), atunci BLL și DAL nu trebuie schimbate, cu excepția interfeței; Sau să schimbi SQLServer în Oracle, să înlocuiești SQLServerDAL cu OracleDAL, fără alte operații necesare, etc. Inițial am vrut să adaug un cod specific articolului, dar nu cred că este necesar, dacă tu consideri că este necesar, îl voi adăuga.
Rezumat: Nu crede că un strat este inutil doar pentru că este inutil pentru tine, sau este deosebit de simplu de implementat, sau abandonat, sau folosit în alte scopuri. Atâta timp cât straturile sunt realizate, indiferent de câte straturi există, fiecare strat trebuie să aibă un scop și o funcție clară de realizare și să nu fie influențat de procesul propriu-zis, rezultând astfel ca același tip de fișier să fie plasat în straturi diferite. Nu lăsa același strat să implementeze funcții diferite. |
Postat pe 07.05.2015 10:53:35
|
|
|
