BLL je plast poslovne logike
DAL je plast za dostop do podatkov
Trinivojska arhitektura ASP.NET (DAL, BLL, UI)
Grafika predstavlja triplastno strukturo. Splet je sloj USL
Web –> BLL –> Dal
| | |
| V |
+–> model <—+
1. Trinivojska arhitektura
1. Predstavitvena plast (USL): Večinoma predstavlja metodo WEB, lahko pa se izrazi tudi kot način WINFORM. Če je logična plast precej robustna in dobro uveljavljena, bo služila popolno ne glede na to, kako je plast zmogljivosti definirana in spremenjena.
2. Poslovna logična plast (BLL): predvsem za specifične probleme jo lahko razumemo tudi kot delovanje podatkovne plasti in logično obdelavo podatkovnega poslovanja. Če je podatkovna plast gradnik, potem je logična plast gradnik.
3. Plast dostopa do podatkov (DAL): To je predvsem operacijska plast izvirnih podatkov (v obliki podatkovne baze, besedilne datoteke ali druge oblike shranjevanja podatkov), ne pa izvirni podatki, torej delovanje podatkov, ne baze podatkov, posebej poslovne logike ali predstavitvene plasti
Zagotavljanje podatkovnih storitev.
2. Specifična razlika
1. Predstavitvena plast: večinoma sprejema uporabnikove zahteve in vrača podatke, kar odjemalcu omogoča dostop do aplikacije.
2. Poslovna logična plast: predvsem odgovorna za delovanje podatkovne plasti, torej za kombinacijo nekaterih operacij podatkovne plasti.
3. Plast dostopa do podatkov: Odvisno je predvsem od tega, ali vaš podatkovni sloj vsebuje logično procesiranje; dejansko njegove funkcije večinoma izvajajo različne operacije na podatkovni datoteki in se ne rabijo ukvarjati z drugimi operacijami.
3. Povzetek
Triplastna struktura je strogo hierarhičen pristop, to pomeni, da lahko do plasti za dostop do podatkov (DAL) dostopa le plast poslovne logike (BLL), plast poslovne logike pa le plast predstavitve (USL). Nekatere triplastne strukture dodajajo tudi druge plasti, kot sta Factory in Model, ki sta pravzaprav razširitev in aplikacija na podlagi teh treh plasti.
Preprost trislojni program običajno vključuje več projektov DAL BLL WEB modela, njihove medsebojne reference pa so naslednje
1) SPLETNE reference BLL, model
2) BLL se sklicuje na DAL, model
3) Model referenc DAL
4) Model nima citatov
Ko gre za trinivojsko arhitekturo, vsi vedo, da gre za plast zmogljivosti (UI), plast poslovne logike (BLL) in plast dostopa do podatkov (DAL), in obstaja veliko načinov za razdelitev vsake plasti. Kako napisati točno kodo in v kateri plasti so te datoteke štete, pa je nejasno. Spodaj je preprost primer, ki vas bo spodbudil k izvajanju projekta s tremi plastmi arhitekture; ta primer ima le eno funkcijo, in sicer preprosto upravljanje uporabnikov.
Najprej ustvarite prazno rešitev in dodajte naslednje elemente in datoteke
1. Dodati ASP.NET projekt spletne aplikacije, poimenovati ga UI in ustvariti novo datoteko spletnega obrazca User.aspx (vključno z User.aspx.cs)
2. Dodajte projekt ClassLibrary, ga poimenujte BLL in ustvarite novo datoteko razreda UserBLL.cs
3. Dodajte projekt ClassLibrary, ga poimenujte DAL in ustvarite novo datoteko razreda UserDAL.cs. Dodaj referenco za SQLHelper. (To je Microsoftov razred za dostop do podatkov, ali pa lahko vso kodo za dostop do podatkov napišete neposredno.) Običajno uporabljam razred DataAccessHelper, ki ga napišem).
4. Dodajte projekt ClassLibrary, ga poimenujte Model in ustvarite novo datoteko tipa razreda UserModel.cs
5. Dodajte projekt ClassLibrary, ga poimenujte IDAL in ustvarite novo datoteko vmesnika IUserDAL.cs
6. Dodajte projekt ClassLibrary in ga poimenujte ClassFactory
Verjamem, da ste videli, da to ni nič drugače kot v primeru Petshopa in je preprostejše, ker se tudi sam skozi Petshop učim triplastne arhitekture. Vendar pa so nekateri prijatelji morda nejasni glede ravni teh projektov in odnosa med njimi, tukaj je razlaga enega za drugim:
1. User.aspx in User.aspx.cs
Oba dokumenta (in elementi, katerim datoteka pripada, kot tudi spodaj, se ne bodo ponavljali) so del predstavitvene plasti. User.aspx je lažje razumeti, ker je prikazna stran. User.aspx.cs nekateri menijo, da ga ne bi smeli šteti, ampak bi ga morali vključiti v plast poslovne logike. Če ne izvajate plastenja, potem ni težav, da User.aspx.cs prepustite upravljanje poslovne logike in celo upravljanje baze podatkov, če pa to počnete, tega ne bi smeli početi. V hierarhični strukturi bi User.aspx.cs moral obravnavati le vsebino, povezano z prikazom, in ničesar drugega ne bi smeli pokrivati.
Na primer, če implementiramo funkcijo prikazovanja uporabnikov v obliki seznama, potem delo pridobivanja informacij opravi BLL, in ko uporabniški vmesnik (v tem primeru je User.aspx.cs) pokliče BLL za pridobitev UserInfo, je ta vezan na nadzor podatkov User.aspx preko kode, da se omogoči prikaz seznama. V tem procesu, User.aspx.cs ne igra vloge v uporabniškem vmesniku, se uporablja le za prenos podatkov, in ker je večina dejanske kode implementirana na ta način, nekateri menijo, da User.aspx.cs ne bi smeli šteti kot uporabniški vmesnik, temveč bi ga morali združiti v BLL za logično obdelavo. Če pogledamo naprej, je bila predlagana nova zahteva, da se pred vsakega uporabnika doda ikona, ki živo predstavlja spol uporabnika, pri mlajših od 18 let pa je bila ta ikona predstavljena z otroško ikono. Uresničitev te zahteve je na vrsti User.aspx.cs, in v tem primeru User.aspx.cs ima to resnično uporabo.
2、NewBLL.cs
Dodajte naslednje metode:
public IList GetUsers(): vrne seznam vseh uporabniških informacij
public UserInfo GetUser(int UserId): Vrne podatke o določenem uporabniku
javni bool AddUser(UserInfo User): Dodane uporabniške informacije
javni bool ChangeUser(UserInfo User): Posodablja uporabniške podatke
public void RemoveUser(int UserId): Odstrani uporabniške podatke
Ta datoteka spada v plast poslovne logike in je namenjena obravnavi operacij, povezanih s poslovno logiko. Mnogi morda mislijo, da je edina uporaba te plasti posredovanje podatkov iz plasti zmogljivosti na podatkovno plast. Res je veliko takšnih primerov, vendar to lahko pomeni le, da je projekt razmeroma preprost ali da odnos med projektom in podjetjem ni tesno povezan (kot na primer trenutno priljubljeni MIS), zato poslovni sloj nima nič za početi in ima le vlogo posredovanja. A to ne pomeni, da je poslovna plast odvečna, saj bo poslovna plast z rastjo projekta ali več poslovnih odnosov odražala njeno vlogo.
Najverjetnejša napaka tukaj je, da se koda za upravljanje podatkov dodeli plasti poslovne logike, podatkovna baza pa kot plast dostopa do podatkov.
Na primer, nekateri prijatelji menijo, da plast BLL nima pomena, ampak samo naložijo DAL podatke in jih posredujejo v uporabniški vmesnik brez kakršnekoli obdelave. Poglejte ta primer
BLL plast
SelectUser(UserInfoInfo) pridobi uporabniške podatke glede na uporabniško ime ali e-pošto, ki prejme.
IsExist(UserInfoInformation) določa, ali obstaja določeno uporabniško ime ali e-pošta.
DAL nato zagotavlja tudi ustrezno metodo za klic BLL
SelectUser(UserInfo)
IsExist(UserInfoUserInfo)
Na ta način BLL igra le vlogo prenosa.
Če pa to storite:
BLL. IsExist(uporabniške informacije)
{
UerInfo user = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Potem DAL ne potrebuje implementacije metode IsExist(), v BLL pa je logična procesna koda.
3、UserModel.cs
Entiteta, to stvar, morda mislite, da ni lahko razčleniti. Vključno z mano sem to razumel takole: UI?àModel?àBLL?àModel?àDAL, zato se verjame, da Model deluje kot most za prenos podatkov med plastmi. A tukaj ne razmišljamo o preprostih stvareh, temveč o kompleksnosti.
Kaj je model? Ni nič! V tridimenzionalni arhitekturi je odveč. Pravzaprav je to najbolj osnovna stvar v objektno usmerjenem programiranju: razredi. Tabela je razred, novica je prav tako razred, int, string, doublie itd. so prav tako razredi, to je le razred.
Na ta način je položaj modela v triplastni arhitekturi enak statusu spremenljivk, kot sta int in string, in nima drugega namena, uporablja se le za shranjevanje podatkov, vendar shranjuje kompleksne podatke. Zato, če so objekti v vašem projektu zelo preprosti, lahko neposredno posredujete več parametrov brez modela in ustvarite triplastno arhitekturo.
Zakaj torej potrebujete model in kakšne so njegove prednosti? Naslednje je, kar mi pride na misel, ko razmišljam o vprašanju, vstavljeno tukaj:
Ali lahko model igra večjo vlogo pri prenosu parametrov na vsaki plasti?
Pri prenašanju parametrov med plastmi lahko storite naslednje:
AddUser(userId,username,userPassword,...,)
Lahko je tudi takole:
AddUser(userInfo)
Katera od teh dveh metod je boljša? Na prvi pogled mora biti druga veliko boljša.
Kdaj posredovati parametre med plastmi z običajnimi tipi spremenljivk (int, string, guid, double) in kaj prenesti z Modelom? Naslednje metode:
SelectUser(int UserId)
SelectUserByName (uporabniško ime v nizu)
SelectUserByName (uporabniško ime, geslo za niz)
SelectUserByEmail (string email)
SelectUserByEmail (string email, string password)
Lahko ga povzamemo kot:
SelectUser(userId)
SelectUser(user)
Tukaj uporabljamo objekt uporabniškega modela, ki vključuje štiri kombinirane načine: uporabniško ime, geslo in e-pošto. UserId je mogoče združiti tudi z userjem, vendar drugi BLL v projektu implementirajo vmesnike z id parametri, zato je ta element prav tako ohranjen.
userInfo se prenese, tako da kako ravnati s tem, to mora biti v vrstnem redu, obstaja določena koda, ki jo je treba določiti.
Tukaj je obdelan v tem vrstnem redu
Najprej preverite, ali imate tako uporabniško ime kot geslo, nato preverite, ali imate tako e-pošto kot geslo, nato preverite, ali imate uporabniško ime, in nato preverite, ali imate e-pošto. Obdelano zaporedno.
Na ta način, če se v prihodnosti doda nova vsebina, članska kartica (številka), ni potrebe po spreminjanju vmesnika, le podpora za številko v DAL kodi in nato v ospredju doda zmogljivost in obdelavo vsebine članske kartice.
4、UserDAL.cs
public IList SelectUsers(): vrne seznam vseh uporabniških informacij
javni UserInfo SelectUser(int UserId): Vrne zaupanja vredne podatke določenega uporabnika
javni bool InsertUser(UserInfo User): Dodane uporabniške informacije
javni bool UpdateUser(UserInfo User): Posodablja informacije o uporabniku
public void DeleteUser(int UserId): Odstrani uporabniške podatke
Kar mnogi ljudje najbolj ne razumejo, je plast dostopa do podatkov, kateri del se šteje za plast dostopa do podatkov? Nekateri menijo, da je podatkovna baza plast dostopa do podatkov, kar ni jasno glede definicije; DAL je plast dostopa do podatkov, ne plast shranjevanja podatkov, zato podatkovna baza ne more biti ta plast. Vloga SQLHelperja je zmanjšati ponavljajoče se programiranje in izboljšati učinkovitost kodiranja, zato če sem vajen skrbeti za učinkovitost ali uporabljati podatkovni vir, ki ni baza podatkov, lahko zavržem SQLHelper, del, ki ga lahko po želji zavržem, kako lahko postane plast triplastne arhitekture.
Lahko ga definiramo takole: koda, povezana z operacijami z virom podatkov, mora biti umeščena v sloj dostopa do podatkov, ki pripada sloju dostopa do podatkov
5、IUserDAL
Vmesnik za dostop do podatkov, to je še ena odvečna stvar, saj Petshop prinaša to in ClassFactory z njim, zato nekateri projekti počnejo ti dve stvari ne glede na to, ali potrebujejo podporo več virov podatkov ali ne, nekateri pa celo ne zgradijo ClassFactory, ampak le IDAL, in nato "IUserDAL iUserDal = novi UserDAL(); Ne vem, kaj to pomeni. To je popolnoma tiger in ne proti-pes.
Veliko ljudi ima tu zmotno predstavo, da obstaja takšno razmerje: BLL?àIDAL?àDAL, kjer mislijo, da IDAL deluje kot most med BLL in DAL, BLL pa DAL kliče preko IDAL. A resnica je, da tudi če to kodirate takole: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Pri izvajanju "iUserDal.SelectUsers()" se dejansko izvaja instanca UserDAL, ne instanca IUserDAL, zato je položaj IDAL v tretji plasti povezan z DAL nivojem.
Skozi zgornji uvod je v osnovi pojasnjena hierarhija trinijske arhitekture. Pravzaprav imam način, da presodim, ali je arhitektura s tremi plastmi standardna, torej popolna zamenjava katere koli od treh plasti ne bo vplivala na preostali dve plasti, in takšna struktura v osnovi ustreza standardu treh plasti (čeprav je ^_^ težja za implementacijo). Na primer, če spremenite projekt iz B/S v C/S (ali obratno), potem BLL in DAL ni treba spreminjati, razen uporabniškega vmesnika; Ali pa spremenite SQLServer v Oracle, preprosto zamenjajte SQLServerDAL z OracleDAL, druge operacije niso potrebne itd. Sprva sem želel dodati nekaj specifične kode v članek, vendar menim, da ni potrebno; če menite, da je potrebno, jo bom dodal.
Povzetek: Ne mislite, da je plast nepotrebna samo zato, ker vam je neuporabna, ali je posebej enostavna za implementacijo, ali jo opustite, ali uporabite za druge namene. Dokler so plasti izvedene, ne glede na število plasti, mora imeti vsaka plast jasen namen in uresničitev funkcije ter je ne sme vplivati dejanski proces, kar pomeni, da se ista vrsta datoteke nahaja v različnih plasteh. Ne dovolite, da ista plast izvaja različne funkcije. |
Objavljeno na 7. 05. 2015 10:53:35
|
|
|
