BLL je vrstva Business Logic
DAL je vrstva prístupu k dátam
Trojúrovňová architektúra ASP.NET (DAL, BLL, UI)
Grafika predstavuje trojvrstvovú štruktúru. Web je vrstva USL
Web –> bll –> Dal
| | |
| V |
+–> model <—+
1. Trojúrovňová architektúra
1. Prezentačná vrstva (USL): Hlavne reprezentuje metódu WEB, ale môže byť vyjadrená aj ako režim WINFORM. Ak je logická vrstva pomerne robustná a dobre zavedená, bude slúžiť perfektne bez ohľadu na to, ako je výkonnostná vrstva definovaná a zmenená.
2. Vrstva podnikovej logiky (BLL): hlavne pri špecifických problémoch, možno ju chápať aj ako prevádzku dátovej vrstvy a logické spracovanie dátového podnikania. Ak je dátová vrstva stavebnými kameňmi, potom logická vrstva je stavebným kameňom.
3. Vrstva prístupu k dátam (DAL): Je to hlavne operačná vrstva pôvodných dát (vo forme databázy, textového súboru alebo inej formy ukladania dát), nie pôvodných dát, teda prevádzka dát, nie databáza, konkrétne vrstva obchodnej logiky alebo prezentačnej vrstvy
Poskytovanie dátových služieb.
2. Špecifické rozlíšenie
1. Prezentačná vrstva: hlavne prijíma požiadavky používateľa a vracia dáta, čím klientovi poskytuje prístup k aplikácii.
2. Vrstva obchodnej logiky: hlavne zodpovedná za prevádzku dátovej vrstvy, teda za kombináciu niektorých operácií na dátovej vrstve.
3. Vrstva prístupu k dátam: Závisí to najmä od toho, či vaša dátová vrstva obsahuje logické spracovanie, v skutočnosti jej funkcie vykonávajú rôzne operácie na dátovom súbore a nemusia sa obávať iných operácií.
3. Zhrnutie
Trojvrstvová štruktúra je prísny hierarchický prístup, teda vrstva prístupu k dátam (DAL) je prístupná iba vrstvou podnikovej logiky (BLL) a vrstva obchodnej logiky iba prezentačnou vrstvou (USL). Niektoré trojvrstvové štruktúry pridávajú aj ďalšie vrstvy, ako napríklad Factory a Model, ktoré sú v skutočnosti rozšírením a aplikáciou na základe týchto troch vrstiev.
Jednoduchý trojvrstvový program zvyčajne zahŕňa niekoľko projektov webového modelu DAL BLL a ich vzájomné referencie sú nasledovné
1) WEB odkazuje BLL, Model
2) BLL odkazuje na DAL, Model
3) Model referencií DAL
4) Model nemá žiadne citácie
Pokiaľ ide o trojúrovňovú architektúru, každý vie, že ide o výkonnostnú vrstvu (UI), vrstvu obchodnej logiky (BLL) a vrstvu prístupu k dátam (DAL), pričom existuje mnoho spôsobov, ako každú vrstvu rozdeliť. Ale ako napísať konkrétny kód a do ktorej vrstvy sa tieto súbory počítajú, je nejasné. Nasleduje jednoduchý príklad, ktorý vás privedie k precvičeniu trojvrstvového architektonického projektu, tento príklad má len jednu funkciu, a to jednoduché riadenie používateľov.
Najprv vytvorte prázdne riešenie a pridajte nasledujúce položky a súbory
1. Pridať ASP.NET projekt webovej aplikácie, pomenovať ho používateľským rozhraním a vytvoriť nový súbor webového formulára User.aspx (vrátane User.aspx.cs)
2. Pridať projekt ClassLibrary, nazvať ho BLL a vytvoriť nový súbor triedy UserBLL.cs
3. Pridať projekt ClassLibrary, nazvať ho DAL a vytvoriť nový súbor triedy UserDAL.cs. Pridajte referenciu na SQLHelper. (Toto je trieda prístupu k dátam od Microsoftu, alebo môžete všetok kód na prístup k dátam napísať priamo.) Zvyčajne používam triedu DataAccessHelper, ktorú píšem).
4. Pridať projekt ClassLibrary, nazvať ho Model a vytvoriť nový súbor typu triedy UserModel.cs
5. Pridať projekt ClassLibrary, nazvať ho IDAL a vytvoriť nový súbor rozhrania IUserDAL.cs
6. Pridať projekt ClassLibrary a nazvať ho ClassFactory
Myslím, že ste videli, že to nie je iné, ako je to v Petshope, a je to jednoduchšie, pretože aj ja sa cez Petshop učím trojvrstvovú architektúru. Niektorí priatelia však môžu byť nejasní ohľadom úrovne týchto projektov a vzťahu medzi nimi, tu je ich vysvetlenie jeden po druhom:
1. User.aspx a User.aspx.cs
Oba dokumenty (a položky, ku ktorým súbor patrí, ako aj nižšie, sa nebudú opakovať) sú súčasťou prezentačnej vrstvy. User.aspx je ľahšie pochopiteľné, pretože ide o zobrazovaciu stránku. User.aspx.cs niektorí ľudia si myslia, že by sa nemal počítať, ale mal by byť zahrnutý do vrstvy obchodnej logiky. Ak nerobíte vrstvenie, nie je problém nechať User.aspx.cs spravovať obchodnú logiku a dokonca prevádzkovať databázu, ale ak vrstvenie, nemalo by sa to robiť. V hierarchickej štruktúre by User.aspx.cs mal riešiť iba obsah súvisiaci s zobrazovaním a nič iné by sa nemalo pokrývať.
Napríklad, ak implementujeme funkciu zobrazovania používateľov vo forme zoznamu, potom prácu extrakcie informácií vykonáva BLL, a po tom, čo používateľské rozhranie (v tomto prípade je to User.aspx.cs) zavolá BLL na získanie UserInfo, je to viazané na kontrolu dát User.aspx cez kód, aby sa zrealizovalo zobrazenie zoznamu. V tomto procese, User.aspx.cs nehrá úlohu v používateľskom rozhraní, používa sa len na odovzdávanie dát, a keďže väčšina samotného kódovania je takto implementovaná, niektorí ľudia cítia, že User.aspx.cs by sa nemala považovať za UI, ale mala by byť zlúčená do BLL na logické spracovanie. Pri ďalšom pohľade bola predložená nová požiadavka pridať ikonu pred každého používateľa, ktorá by živo reprezentovala jeho pohlavie, a pre osoby mladšie ako 18 rokov bola táto ikona reprezentovaná detskou ikonou. Splnenie tejto požiadavky je obratom User.aspx.cs, a v tomto prípade User.aspx.cs má skutočné využitie.
2、NewBLL.cs
Pridajte nasledujúce metódy:
public IList GetUsers(): Vráti zoznam všetkých informácií o používateľovi
public UserInfo GetUser(int UserId): Vracia údaje o špecifikovanom používateľovi
verejný bool AddUser(UserInfo User): Pridané informácie o používateľovi
verejný bool ChangeUser(UserInfo User): Aktualizuje informácie o používateľovi
public void RemoveUser(int UserId): Odstraňuje informácie o používateľovi
Tento súbor patrí do vrstvy obchodnej logiky a je určený na spracovanie operácií súvisiacich s obchodnou logikou. Mnohí si môžu myslieť, že jediné využitie tejto vrstvy je na preposielanie dát z výkonnostnej vrstvy na túto vrstvu. Takýchto prípadov je naozaj veľa, ale to môže znamenať len to, že projekt je relatívne jednoduchý alebo že vzťah medzi samotným projektom a podnikom nie je úzko prepojený (ako súčasný populárny MIS), takže obchodná vrstva nemá čo robiť a hrá len úlohu forwardingu. To však neznamená, že obchodná vrstva je zbytočná, keďže projekt rastie alebo je viac obchodných vzťahov, obchodná vrstva bude odrážať jej úlohu.
Najpravdepodobnejšou chybou je priradiť kód operácie s dátami na vrstvu business logickej logiky a databázu ako vrstvu prístupu k dátam.
Napríklad niektorí priatelia si myslia, že vrstva BLL nie je významná, ale jednoducho nahrajú DAL dáta a prepošlú ich do používateľského rozhrania bez akéhokoľvek spracovania. Pozrite sa na tento príklad
BLL vrstva
SelectUser(UserInfoInfo) získava údaje o používateľovi na základe používateľského mena alebo e-mailu, ktorý príde.
IsExist(UserInfoInfo) určuje, či existuje uvedené používateľské meno alebo e-mail.
Potom DAL tiež poskytuje zodpovedajúcu metódu pre volanie BLL
SelectUser(UserInfoUserInfo)
IsExist(UserInfoUserInfo)
Týmto spôsobom BLL zohráva iba prenosovú úlohu.
Ale ak áno:
BLL. IsExist(Userinfo userinfo)
{
UerInfo user = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Potom DAL nemusí implementovať metódu IsExist() a v BLL existuje logický spracovateľský kód.
3、UserModel.cs
Entita, táto vec, možno si myslíte, že nie je ľahké ju stratifikovať. Vrátane mňa som to chápal takto: UI?àModel?àBLL?àModel?àDAL, takže sa verí, že Model slúži ako most pre prenos dát medzi vrstvami. Ale tu nerozmýšľame o jednoduchých veciach, ale o zložitosti.
Čo je Model? To nič nie je! V trojstupňovej architektúre je to nahraditeľné. V skutočnosti je to najzákladnejšia vec v objektovo orientovanom programovaní: triedy. Tabuľka je trieda, news je tiež trieda, int, string, doublie a podobne sú tiež triedy, je to len trieda.
Týmto spôsobom je pozícia modelu v trojvrstvovej architektúre rovnaká ako stav premenných, ako sú int a string, a nemá iný účel, používa sa len na ukladanie dát, ale uchováva zložité dáta. Preto, ak sú objekty vo vašom projekte veľmi jednoduché, môžete priamo posielať viaceré parametre bez modelu a vytvoriť trojvrstvovú architektúru.
Tak prečo potrebujete model a aké sú jeho výhody? Nasleduje to, čo mi napadne, keď premýšľam nad otázkou, vložené tu:
Môže model zohrávať väčšiu úlohu pri odovzdávaní parametrov na každej vrstve?
Pri prenášaní parametrov medzi vrstvami môžete urobiť nasledovné:
AddUser(userId,username,userPassword,...,)
Môže to byť aj takto:
AddUser(userInfo)
Ktorá z týchto dvoch metód je lepšia? Na prvý pohľad to musí byť ten druhý oveľa lepší.
Kedy posielať parametre medzi vrstvami s normálnymi typmi premenných (int, string, guid, double) a čo posielať s Modelom? Nasledujúce metódy:
SelectUser(int UserId)
SelectUserByName(reťazcové používateľské meno)
SelectUserByName(reťazec používateľského mena, reťazcové heslo)
SelectUserByEmail (reťazový email)
SelectUserByEmail (reťazec email, reťazec hesla)
Dá sa zhrnúť takto:
SelectUser(userId)
SelectUser(user)
Tu používame objekt používateľského modelu na zahrnutie štyroch kombinovaných režimov: používateľské meno, heslo a e-mail. UserId sa tiež môže zlúčiť s user, ale iné BLL v projekte implementujú rozhrania s id parametrami, takže tento element je tiež zachovaný.
userInfo sa odovzdáva, takže ako to riešiť, musí to byť v poradí podľa poradia, musí sa rozhodnúť konkrétny kód.
Tu sa spracováva v tomto poradí
Najprv sa pozrite, či máte používateľské meno aj heslo, potom či máte e-mail aj heslo, potom či máte používateľské meno, a nakoniec skontrolujte, či máte e-mail. Spracované postupne.
Týmto spôsobom, ak sa v budúcnosti pridá nový obsah, členská karta (číslo), nie je potrebné meniť rozhranie, stačí pridať podporu čísla do DAL kódu a potom pridať výkon a spracovanie obsahu členstva v popredí.
4、UserDAL.cs
public IList SelectUsers(): Vráti zoznam všetkých informácií o používateľovi
public UserInfo SelectUser(int UserId): Vracia dôveryhodné informácie o špecifikovanom používateľovi
public bool InsertUser(UserInfo User): Pridané informácie o používateľovi
verejný bool UpdateUser(UserInfo User): Aktualizuje informácie o používateľovi
public void DeleteUser(int UserId): Odstráni informácie o používateľovi
Čo mnohí ľudia najviac nechápu, je vrstva prístupu k dátam, ktorá časť sa považuje za vrstvu prístupu k dátam? Niektorí ľudia si myslia, že databáza je vrstva prístupu k dátam, čo nie je jasné v definícii, DAL je vrstva prístupu k dátam, nie vrstva ukladania dát, takže databáza nemôže byť touto vrstvou. Úlohou SQLHelperu je znížiť opakujúce sa kódovanie a zlepšiť efektivitu programovania, takže ak som zvyknutý starať sa o efektivitu alebo používať zdroj dát mimo databázy, môžem SQLHelper zahodiť, časť, ktorú možno kedykoľvek zahodiť, ako sa môže stať vrstvou trojvrstvovej architektúry.
Dá sa definovať nasledovne: kód súvisiaci s operáciami so zdrojom dát by mal byť umiestnený vo vrstve prístupu k dátam, ktorá patrí do vrstvy prístupu k dátam
5、IUserDAL
Rozhranie dátovej prístupovej vrstvy, to je ďalšia zbytočná vec, pretože Petshop ho prináša spolu s ClassFactory Factory, takže niektoré projekty robia tieto dve veci bez ohľadu na to, či potrebujú podporovať viacero dátových zdrojov alebo nie, a niektoré dokonca nestavajú ClassFactory, ale len IDAL, a potom "IUserDAL iUserDal = nový UserDAL(); Neviem, čo to znamená. Toto je úplne tiger, nie proti-pes.
Mnohí ľudia tu majú mylnú predstavu, že existuje takýto vzťah: BLL?àIDAL?àDAL, mysliac si, že IDAL slúži ako most medzi BLL a DAL, a BLL volá DAL cez IDAL. Ale realita je taká, že aj keď to naprogramujete takto: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Pri vykonávaní "iUserDal.SelectUsers()" sa v skutočnosti vykonáva inštancia UserDAL, nie inštancia IUserDAL, takže pozícia IDAL v tretej vrstve súvisí s úrovňou DAL.
Prostredníctvom vyššie uvedeného úvodu je hierarchia trojúrovňovej architektúry v podstate vysvetlená. V skutočnosti mám spôsob, ako posúdiť, či je trojvrstvová architektúra štandardná, teda úplné nahradenie ktorejkoľvek z troch vrstiev neovplyvní ostatné dve vrstvy, a takáto štruktúra v podstate spĺňa trojvrstvový štandard (hoci je ^_^ náročnejšia na implementáciu). Napríklad, ak zmeníte projekt z B/S na C/S (alebo naopak), BLL a DAL sa nemusia meniť okrem používateľského rozhrania; Alebo zmeniť SQLServer na Oracle, jednoducho nahradiť SQLServerDAL za OracleDAL, žiadne ďalšie operácie nie sú potrebné, atď. Pôvodne som chcel pridať nejaký konkrétny kód do článku, ale nemyslím si, že je to potrebné, ak to považujete za potrebné, pridám ho.
Zhrnutie: Nemyslite si, že vrstva je zbytočná len preto, že je pre vás zbytočná, alebo je obzvlášť jednoduchá na implementáciu, alebo ju opustiť, alebo použiť na iné účely. Pokiaľ sú vrstvy vykonané, bez ohľadu na počet vrstiev, každá vrstva musí mať jasný účel a funkčné využitie a nemala by byť ovplyvnená samotným procesom, čo vedie k tomu, že rovnaký typ súboru bude umiestnený v rôznych vrstvách. Nedovoľ, aby tá istá vrstva implementovala rôzne funkcie. |
Zverejnené 7. 5. 2015 10:53:35
|
|
|
