BLL on äriloogika kiht
DAL on andmejuurdepääsu kiht
Kolmetasandiline arhitektuur ASP.NET (DAL, BLL, UI)
Graafika esindab kolmekihilist struktuuri. Veeb on USL-kiht
veeb –> bll –> dal
| | |
| V |
+–> mudel <—+
1. Kolmetasandiline arhitektuur
1. Esitluskiht (USL): See esindab peamiselt WEB-meetodit, kuid seda saab väljendada ka WINFORM režiimina. Kui loogikakiht on üsna robustne ja hästi juurdunud, teenib see ideaalselt, ükskõik kuidas jõudluskiht on defineeritud ja muudetud.
2. Äriloogika kiht (BLL): peamiselt konkreetsete probleemide puhul, seda võib mõista ka andmekihi toimimise ja andmeäri loogilise töötlemisena. Kui andmekiht on ehitusplokid, siis loogikakiht on ehitusplokk.
3. Andmejuurdepääsu kiht (DAL): See on peamiselt algse andmete töökiht (andmebaasi, tekstifaili või muu andmete salvestamise vormis), mitte originaalandmed, st andmete toimimine, mitte andmebaas, täpsemalt äriloogika kiht või esitluskiht
Andmeteenuste pakkumine.
2. Spetsiifiline eristus
1. Esitluskiht: võtab peamiselt vastu kasutaja päringu ja tagastab andmeid, võimaldades kliendil rakendusele ligipääsu.
2. Äriloogika kiht: peamiselt vastutab andmekihi toimimise eest, st mõnede andmekihi operatsioonide kombinatsiooni eest.
3. Andmejuurdepääsu kiht: See sõltub peamiselt sellest, kas sinu andmekiht sisaldab loogilist töötlemist, tegelikult täidavad selle funktsioonid peamiselt erinevaid toiminguid andmefailis ega pea muretsema teiste operatsioonide pärast.
3. Kokkuvõte
Kolmekihiline struktuur on range hierarhiline lähenemine, see tähendab, et andmejuurdepääsu kiht (DAL) on ligipääsetav ainult äriloogika kihi (BLL) kaudu ja äriloogika kiht ainult esitluskihi (USL) kaudu. Mõned kolmekihilised struktuurid lisavad ka teisi kihte, nagu tehas ja mudel, mis on tegelikult laiendus ja rakendus nende kolme kihi alusel.
Lihtne kolmekihiline programm hõlmab tavaliselt mitut DAL BLL veebimudeli projekti ning nende ühised viited on järgmised
1) WEB viited BLL, mudel
2) BLL viitab DAL-ile, mudelile
3) DAL viited mudelile
4) Mudelil puuduvad viited
Kolmekihilise arhitektuuri puhul teavad kõik, et see on jõudluskiht (UI), äriloogika kiht (BLL) ja andmejuurdepääsu kiht (DAL) ning iga kihi jagamiseks on palju võimalusi. Kuid kuidas konkreetset koodi kirjutada ja millises kihis need failid arvestatakse, on ebaselge. Järgmine on lihtne näide, mis juhatab sind kolmekihilise arhitektuuriprojekti harjutamiseni, sellel näitel on ainult üks funktsioon – kasutajate lihtne haldamine.
Esiteks loo tühi lahendus ja lisa järgmised elemendid ja failid
1. Lisa ASP.NET veebirakenduse projekt, nimeta see kasutajaliides ja loo uus veebivormi fail User.aspx (sh User.aspx.cs)
2. Lisa ClassLibrary projekt, nimeta see BLL ja loo uus Class fail UserBLL.cs
3. Lisa ClassLibrary projekt, nimeta see DAL-iks ja loo uus Class fail UserDAL.cs. Lisa SQLHelperi viide. (See on Microsofti andmejuurdepääsu kursus või saad kogu andmekoodi otse kirjutada.) Tavaliselt kasutan DataAccessHelper klassi, mida kirjutan).
4. Lisa ClassLibrary projekt, nimeta see Modeliks ja loo uus Class tüüpi fail UserModel.cs
5. Lisa ClassLibrary projekt, nimeta see IDAL-iks ja loo uus liidese fail IUserDAL.cs
6. Lisa ClassLibrary projekt ja nimeta see ClassFactoryks
Usun, et olete näinud, et see pole Petshopi näitest erinev ja on lihtsam, sest õpin ka kolmekihilist arhitektuuri Petshopi kaudu. Siiski võivad mõned sõbrad olla nende projektide taseme ja nendevaheliste suhete osas ebamäärased, siin on selgitus neist ükshaaval:
1. User.aspx ja User.aspx.cs
Mõlemad dokumendid (ja faili kuuluvad üksused, samuti allpool) on osa esitluskihist. User.aspx on lihtsam mõista, sest tegemist on kuvalehega. User.aspx.cs mõned inimesed arvavad, et seda ei tohiks arvestada, vaid see peaks olema kaasatud äriloogika kihti. Kui sa ei tee kihistamist, siis pole probleemi lasta User.aspx.cs äriloogikat hallata ja isegi andmebaasi hallata, kuid kui kihistust kasutad, siis seda ei tohiks teha. Hierarhilises struktuuris peaks User.aspx.cs tegelema ainult kuvamisega seotud sisuga ja midagi muud ei tohiks käsitleda.
Näiteks, kui rakendame kasutajate kuvamise funktsiooni nimekirjana, siis info väljavõtmine toimub BLL-i poolt ning pärast kasutajaliides (antud juhul User.aspx.cs) kutsub BLL-i, et saada UserInfo, on see seotud User.aspx andmekontrolliga koodi kaudu, et loendi kuvamine realiseerida. Selles protsessis User.aspx.cs see ei mängi kasutajaliideses rolli, seda kasutatakse ainult andmete edastamiseks, ja kuna enamik kodeerimisest on nii teostatud, arvavad mõned, et User.aspx.cs ei tohiks lugeda kasutajaliideseks, vaid tuleks ühendada BLL-iga loogiliseks töötlemiseks. Edasi vaadates kehtestati uus nõue lisada iga kasutaja ette ikoon, et selgelt esindada kasutaja sugu, ning alla 18-aastastele tähistati seda lapseikooniga. Selle nõude realiseerumine on User.aspx.cs käik, ja antud juhul User.aspx.cs sellel on tõeline kasutus.
2、NewBLL.cs
Lisa järgmised meetodid:
public IList GetUsers(): Tagastab kogu kasutajainfo nimekirja
public UserInfo GetUser(int UserId): Tagastab määratud kasutaja andmed
public bool AddUser(UserInfo User): Lisatud kasutajainfo
public bool ChangeUser(UserInfo User): Uuendab kasutajaandmeid
public void RemoveUser(int UserId): Eemaldab kasutajainfo
See fail kuulub äriloogika kihi ja on pühendatud äriloogikaga seotud toimingute käsitlemiseks. Paljud võivad arvata, et selle kihi ainus kasutus on andmete edastamine jõudluskihist andmekihi. Selliseid juhtumeid on tõepoolest palju, kuid see võib tähendada vaid seda, et projekt on suhteliselt lihtne või projekti ja ettevõtte suhe ei ole tihedalt integreeritud (nagu praegune populaarne MIS), seega ärikihil pole midagi rolli ja see mängib ainult edasiandmise rolli. Kuid see ei tähenda, et ärikiht oleks asendamatu – projekti suurenedes või ärisuhete kasvades peegeldab ärikiht oma rolli.
Kõige tõenäolisem viga on määrata andmeoperatsiooni kood äriloogika kihile ja andmebaas andmejuurdepääsu kihiks.
Näiteks mõned sõbrad arvavad, et BLL kiht pole oluline, aga nad lihtsalt laadivad DAL andmed üles ja edastavad need UI-sse ilma töötlemiseta. Vaata seda näidet
BLL kiht
SelectUser(UserInfo userInfo) saab kasutajaandmed vastavalt kasutajanimele või e-posti aadressile, mis saabub.
IsExist(UserInfo userInfo) määrab, kas määratud kasutajanimi või e-post eksisteerib.
Seejärel pakub DAL ka vastava meetodi BLL-kõne jaoks
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Nii mängib BLL ainult ülekanderolli.
Aga kui sa seda teed:
BLL. IsExist(Kasutajainfo kasutajainfo)
{
UerInfo kasutaja = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Siis ei pea DAL rakendama IsExist() meetodit ning BLL-is on loogiline töötlemiskood.
3、UserModel.cs
Entiteet, see asi, võid arvata, et seda pole lihtne stratifitseerida. Mina kaasa arvatud mina, mõistsin seda nii: UI?àModel?àBLL?àModel?àDAL, seega usutakse, et mudel toimib sillana andmete edastamiseks kihtide vahel. Aga siin ei mõtle me asjadele lihtsalt, vaid keerukusele.
Mis on mudel? Pole midagi! See on asendamatu kolmetasandilises arhitektuuris. See on tegelikult objektorienteeritud programmeerimises kõige põhilisem asi: klassid. Tabel on klass, uudis on samuti klass, int, string, doublie jne on samuti klassid, see on lihtsalt klass.
Nii on mudeli asukoht kolmekihilises arhitektuuris sama mis muutujate nagu int ja string staatus ning sellel pole muud eesmärki, seda kasutatakse ainult andmete salvestamiseks, kuid see salvestab keerukaid andmeid. Seega, kui sinu projekti objektid on väga lihtsad, saad otse edastada mitu parameetrit ilma mudelita, et luua kolmekihiline arhitektuur.
Miks siis mudelit vaja on ja millised on selle eelised? Järgmine on see, mis tuleb meelde, kui mõelda siia lisatud küsimusele:
Kas mudel võib mängida suuremat rolli parameetrite üleminekul igal kihil?
Parameetrite edastamisel kihtide vahel saab teha järgmist:
AddUser(userId,userName,userPassword,...,)
See võib olla ka selline:
AddUser(userInfo)
Kumb neist kahest meetodist on parem? Esmapilgul pidi see olema teine palju parem.
Millal anda parameetreid kihtide vahel, millel on normaalsed muutujad (int, string, guid, double), ja mida edasi anda mudeliga? Järgmised meetodid:
SelectUser(int UserId)
SelectUserByName(string username)
SelectUserByName(string, kasutajanimi, stringi parool)
SelectUserByEmail (string email)
SelectUserByEmail (string email, string password)
Seda võib kokku võtta järgmiselt:
SelectUser(userId)
SelectUser(kasutaja)
Siin kasutame kasutajamudeli objekti, et lisada neli kasutajanime, parooli ja e-posti kombinatsioonirežiimi. UserID-d saab samuti kasutajaks ühendada, kuid teised projekti BLL-id rakendavad liideseid, millel on id parameetrid, seega säilitatakse ka see üksus.
userInfo on läbitud, nii et kuidas sellega toime tulla, see peab olema järjekorras, on konkreetne kood, mida otsustada.
Siin töödeldakse seda selles järjekorras
Esiteks vaata, kas sul on nii kasutajanimi kui parool, siis kas sul on nii e-post kui parool, siis kas sul on kasutajanimi ja alles siis e-posti aadress. Töödeldud järjestikku.
Nii ei ole vaja liidest muuta, lihtsalt lisada DAL koodi numbri tugi numbrile ning lisada esiplaanile liikmekaardi sisu jõudlus ja töötlemine.
4、UserDAL.cs
public IList SelectUsers(): Tagastab kogu kasutajainfo nimekirja
public UserInfo SelectUser(int UserId): Tagastab määratud kasutaja usaldusväärse info
public bool InsertUser(UserInfo User): Lisatud kasutajainfo
public bool UpdateUser(UserInfo User): Uuendab kasutajaandmeid
public void DeleteUser(int UserId): Eemaldab kasutajainfo
Mida paljud inimesed kõige rohkem ei suuda mõista, on andmejuurdepääsu kiht, millist osa peetakse andmejuurdepääsu kihiks? Mõned inimesed arvavad, et andmebaas on andmejuurdepääsu kiht, mille definitsioon pole selge, DAL on andmejuurdepääsu kiht, mitte andmesalvestuskiht, seega ei saa andmebaas olla see kiht. SQLHelperi roll on vähendada korduvat kodeerimist ja parandada programmeerimise efektiivsust, nii et kui olen harjunud hoolima efektiivsusest või kasutama mitte-andmebaasi andmeallikat, saan ära visata SQLHelperi, osa, mida saab soovi korral ära visata – kuidas see saaks saada kolmekihilise arhitektuuri kihiks.
Seda saab defineerida järgmiselt: andmeallika operatsioonidega seotud kood tuleks paigutada andmejuurdepääsu kihi, mis kuulub andmejuurdepääsu kihi alla
5、IUserDAL
Andmejuurdepääsu kihi liides, see on veel üks asendamatu asi, sest Petshop toob selle ja ClassFactory tehase kaasa, nii et mõned projektid teevad neid kahte asja, sõltumata sellest, kas nad peavad toetama mitut andmeallikat või mitte, ja mõned ei ehita isegi ClassFactoryt, vaid ainult IDAL-i, ja siis "IUserDAL iUserDal = uus UserDAL(); Ma ei tea, mida see tähendab. See on täiesti tiiger, mitte koeravastane.
Paljudel inimestel on siin eksiarvamus, et selline seos eksisteerib: BLL?àIDAL?àDAL, arvates, et IDAL toimib sillana BLL-i ja DAL-i vahel, ning BLL nimetab DAL-i IDAL-i kaudu. Aga tegelikkuses kodeerid selle nii: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Kui käivitatakse "iUserDal.SelectUsers()", siis tegelikult käivitatakse UserDAL instants, mitte IUserDAL instant, seega on IDAL-i positsioon kolmandas kihis seotud DAL tasemega.
Ülaltoodud sissejuhatuse kaudu selgitatakse põhimõtteliselt kolmekihilise arhitektuuri hierarhiat. Tegelikult on mul viis hinnata, kas kolmekihiline arhitektuur on standardne, st ühe kolmekihilise kihi täielik asendamine ei mõjuta teisi kahte kihti, ja selline struktuur vastab põhimõtteliselt kolmekihilisele standardile (kuigi selle rakendamine on keerulisem ^_^). Näiteks, kui muudate projekti B/S-lt C/S-iks (või vastupidi), siis BLL-i ja DAL-i ei pea muutma, välja arvatud kasutajaliides; Või muuda SQLServer Oracle'iks, lihtsalt asenda SQLServerDAL OracleDAL-iks, muid toiminguid pole vaja jne. Alguses tahtsin artiklile lisada konkreetse koodi, aga ma ei pea seda vajalikuks, kui sa tunned, et see on vajalik, lisan selle.
Kokkuvõte: Ära arva, et kiht on tarbetu ainult sellepärast, et see on sulle kasutu või on eriti lihtne rakendada, või loobu sellest või kasuta seda muudel eesmärkidel. Nii kaua kui kihte teostatakse, ükskõik kui palju kihte on, peab igal kihil olema selge eesmärk ja funktsiooni realiseerumine ning see ei tohiks olla protsessist mõjutatud, mistõttu sama tüüpi fail asub erinevates kihtides. Ära lase samal kihil rakendada erinevaid funktsioone. |
Postitatud 07.05.2015 10:53:35
|
|
|
