BLL je vrstva obchodní logiky
DAL je vrstva přístupu k datům
Tříúrovňová architektura ASP.NET (DAL, BLL, UI)
Grafika představuje třívrstvou strukturu. Web je vrstva USL
Web –> BLL –> Dal
| | |
| V |
+–> model <—+
1. Tříúrovňová architektura
1. Prezentační vrstva (USL): Primárně reprezentuje metodu WEB, ale lze ji také vyjádřit jako režim WINFORM. Pokud je logická vrstva poměrně robustní a dobře zavedená, bude sloužit perfektně bez ohledu na to, jak je výkonnostní vrstva definována a změněna.
2. Vrstva obchodní logiky (BLL): hlavně pro specifické problémy, lze ji také chápat jako provoz datové vrstvy a logické zpracování datového podnikání. Pokud je datová vrstva stavebními kameny, pak logická vrstva je stavebním kamenem.
3. Vrstva přístupu k datům (DAL): Jedná se především o operační vrstvu původních dat (ve formě databáze, textového souboru nebo jiné formy ukládání dat), nikoli o původní data, tedy o provoz dat, nikoli o databázi, konkrétně o vrstvu obchodní logiky nebo prezentační vrstvu
Poskytování datových služeb.
2. Specifické rozlišení
1. Prezentační vrstva: převážně přijímá uživatelský požadavek a vrací data, čímž klientovi poskytuje přístup k aplikaci.
2. Vrstva obchodní logiky: hlavně odpovědná za provoz datové vrstvy, tedy kombinaci některých operací datové vrstvy.
3. Vrstva přístupu k datům: Záleží hlavně na tom, zda vaše datová vrstva obsahuje logické zpracování, ve skutečnosti její funkce hlavně provádějí různé operace na datovém souboru a nemusí se starat o jiné operace.
3. Shrnutí
Třívrstvá struktura je přísně hierarchický přístup, tedy vrstva přístupu k datům (DAL) je přístupná pouze vrstvou podnikové logiky (BLL) a vrstvou obchodní logiky pouze prezentační vrstvou (USL). Některé třívrstvé struktury přidávají také další vrstvy, jako jsou Factory a Model, které jsou ve skutečnosti rozšířením a aplikací na základě těchto tří vrstev.
Jednoduchý třívrstvý program obvykle zahrnuje několik projektů webového modelu DAL BLL a jejich vzájemné odkazy jsou následující
1) WEB odkazuje BLL, Model
2) BLL odkazuje na DAL, Model
3) Model referencí DAL
4) Model nemá žádné citace
Pokud jde o třívrstvou architekturu, každý ví, že jde o výkonnostní vrstvu (UI), obchodní logiku (BLL) a vrstvu přístupu k datům (DAL), a existuje mnoho způsobů, jak každou vrstvu rozdělit. Ale jak napsat konkrétní kód a do které vrstvy se tyto soubory počítají, je nejasné. Následuje jednoduchý příklad, který vás přiměje k procvičování třívrstvého architektonického projektu, tento příklad má pouze jednu funkci, a to jednoduchou správu uživatelů.
Nejprve vytvořte prázdné řešení a přidejte následující položky a soubory
1. Přidat ASP.NET projekt webové aplikace, pojmenovat ho UI a vytvořit nový soubor Web Form User.aspx (včetně User.aspx.cs)
2. Přidat projekt ClassLibrary, pojmenovat ho BLL a vytvořit nový soubor třídy UserBLL.cs
3. Přidejte projekt ClassLibrary, pojmenujte ho DAL a vytvořte nový soubor třídy UserDAL.cs. Přidejte referenci na SQLHelper. (Toto je třída přístupu k datům od Microsoftu, nebo můžete napsat veškerý kód pro přístup k datům přímo.) Obvykle používám třídu DataAccessHelper, kterou píšu).
4. Přidejte projekt ClassLibrary, pojmenujte ho Model a vytvořte nový soubor typu třídy UserModel.cs
5. Přidejte projekt ClassLibrary, pojmenujte ho IDAL a vytvořte nový soubor rozhraní IUserDAL.cs
6. Přidejte projekt v ClassLibrary a pojmenujte ho ClassFactory
Myslím, že jste viděli, že se to neliší od příkladu z Petshopu a je to jednodušší, protože se také učím třívrstvou architekturu právě v Petshopu. Někteří přátelé však mohou být vágní ohledně úrovně těchto projektů a vztahu mezi nimi, zde je vysvětlení jednoho po druhém:
1. User.aspx a User.aspx.cs
Oba dokumenty (a položky, ke kterým soubor patří, stejně jako níže, nebudou opakovány) jsou součástí prezentační vrstvy. User.aspx je snazší pochopit, protože je to zobrazovací stránka. User.aspx.cs někteří lidé si myslí, že by se neměl počítat, ale měl by být zahrnut do vrstvy obchodní logiky. Pokud neděláte vrstvení, není problém nechat User.aspx.cs spravovat obchodní logiku a dokonce i provozovat databázi, ale pokud vrstvení, nemělo by se to dělat. V hierarchické struktuře by User.aspx.cs měl řešit pouze obsah související s displejem a nic dalšího by nemělo být pokryto.
Například pokud implementujeme funkci zobrazení uživatelů ve formě seznamu, pak práci na extrakci informací vykonává BLL, a poté, co uživatelské rozhraní (v tomto případě je to User.aspx.cs) zavolá BLL pro získání UserInfo, je to vázáno na řízení dat User.aspx prostřednictvím kódu, aby bylo možné zobrazit seznam. V tomto procesu User.aspx.cs nehraje roli v uživatelském rozhraní, slouží pouze k předávání dat, a protože většina samotného kódu je takto implementována, někteří lidé mají pocit, že User.aspx.cs by nemělo být počítáno jako UI, ale mělo by být sloučeno do BLL pro logické zpracování. Dále byl navržen nový požadavek na přidání ikony před každého uživatele, která by živě reprezentovala pohlaví uživatele, a u osob mladších 18 let byla tato ikona reprezentována ikonou dítěte. Realizace tohoto požadavku je na řadu User.aspx.cs, a v tomto případě User.aspx.cs má skutečné využití.
2、NewBLL.cs
Přidejte následující metody:
public IList GetUsers(): Vrací seznam všech uživatelských informací
public UserInfo GetUser(int UserId): Vrací údaje o specifikovaném uživateli
public bool AddUser(UserInfo User): Přidány uživatelské informace
veřejný bool ChangeUser(UserInfo User): Aktualizuje uživatelské informace
public void RemoveUser(int UserId): Odstraní uživatelské informace
Tento soubor patří do vrstvy business logiky a je věnován zpracování operací souvisejících s business logikou. Mnoho lidí si může myslet, že jediným využitím této vrstvy je přeposílání dat z výkonnostní vrstvy na datovou vrstvu. Takových případů skutečně existuje, ale to může znamenat jen to, že projekt je relativně jednoduchý, nebo že vztah mezi samotným projektem a podnikem není úzce propojen (například současný populární MIS), takže obchodní vrstva nemá co dělat a hraje pouze roli přeposílání. To však neznamená, že obchodní vrstva je nahraditelná, protože jak projekt roste nebo je více obchodních vztahů, obchodní vrstva bude odrážet její roli.
Nejpravděpodobnější chybou je přiřazení kódu operace s daty na vrstvu business logiky a databázi jako vrstvu přístupu k datům.
Například někteří přátelé si myslí, že vrstva BLL není smysluplná, ale prostě nahrají data DAL a přepošlou je do uživatelského rozhraní bez jakéhokoliv zpracování. Podívejte se na tento příklad
BLL vrstva
SelectUser(UserInfoInfo) získává uživatelské údaje na základě uživatelského jména nebo e-mailu, který přijde.
IsExist(UserInfoInfo) určuje, zda existuje uvedené uživatelské jméno nebo e-mail.
DAL pak také poskytuje odpovídající metodu pro volání BLL
SelectUser(UserInfoUserInfo)
IsExist(UserInfoUserInfo)
Tímto způsobem BLL hraje pouze přenosovou roli.
Ale pokud ano:
BLL. IsExist(uživatelské informace)
{
UerInfo user = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Pak DAL nemusí implementovat metodu IsExist() a v BLL je k dispozici logický zpracovatelský kód.
3、UserModel.cs
Entita, tohle, možná si myslíte, že není snadné to stratifikovat. Včetně mě jsem to chápal takto: UI?àModel?àBLL?àModel?àDAL, takže se věří, že Model funguje jako most pro přenos dat mezi vrstvami. Ale tady nepřemýšlíme o jednoduchých věcech, ale o složitosti.
Co je to model? To nic není! Je nahraditelný v tříúrovňové architektuře. Ve skutečnosti je to ta nejzákladnější věc v objektově orientovaném programování: třídy. Tabulka je třída, news je také třída, int, string, doublie atd. jsou také třídy, je to prostě třída.
Tímto způsobem je pozice modelu v třívrstvé architektuře stejná jako stav proměnných jako int a string, a nemá jiný účel, slouží pouze k ukládání dat, ale ukládá složitá data. Pokud jsou objekty ve vašem projektu velmi jednoduché, můžete přímo předávat více parametrů bez modelu a vytvořit třívrstvou architekturu.
Tak proč tedy potřebujete model a jaké jsou jeho výhody? Následující je to, co se vám vybaví, když přemýšlíte o otázce, vložené zde:
Může model hrát větší roli při předávání parametrů na každé vrstvě?
Při předávání parametrů mezi vrstvami můžete udělat následující:
AddUser(userId,userName,userPassword,...,)
Může to být také takto:
AddUser(userInfo)
Která z těchto dvou metod je lepší? Na první pohled musí být ten druhý mnohem lepší.
Kdy předávat parametry mezi vrstvami s normálními typy proměnných (int, string, guid, double) a co předávat pomocí Modelu? Následující metody:
SelectUser(int UserId)
SelectUserByName (uživatelské jméno řetězce)
SelectUserByName (uživatelské jméno řetězce, heslo řetězce)
SelectUserByEmail (řetězec e-mailů)
SelectUserByEmail (řetězec email, řetězec heslo)
Lze ji shrnout takto:
SelectUser(userId)
SelectUser(user)
Zde používáme objekt uživatelského modelu, který zahrnuje čtyři kombinační režimy uživatelského jména, hesla a e-mailu. UserId lze také sloučit s userem, ale ostatní BLL v projektu implementují rozhraní s id parametry, takže i tato položka je zachována.
userInfo se předává, takže jak to řešit, musí to být v pořadí, musí být specifický kód, který je třeba rozhodnout.
Zde je zpracováno v tomto pořadí
Nejprve zjistěte, jestli máte jak uživatelské jméno, tak heslo, pak jestli máte e-mail i heslo, pak zkontrolujte, jestli máte uživatelské jméno, a nakonec e-mail. Zpracovává se postupně.
Tímto způsobem, pokud bude v budoucnu přidán nový obsah, tedy členská karta (číslo), není třeba měnit rozhraní, stačí přidat podporu čísla do DAL kódu a poté přidat výkon a zpracování obsahu členské karty do popředí.
4、UserDAL.cs
public IList SelectUsers(): Vrací seznam všech uživatelských informací
public UserInfo SelectUser(int UserId): Vrací důvěryhodné informace o určeném uživateli
veřejný bool InsertUser(UserInfo User): Přidány uživatelské informace
public bool UpdateUser(UserInfo User): Aktualizuje uživatelské informace
public void DeleteUser(int UserId): Odstraňuje uživatelské informace
Co mnoho lidí nejvíc nechápe, je vrstva přístupu k datům, která část se považuje za vrstvu přístupu k datům? Někteří lidé si myslí, že databáze je vrstva přístupu k datům, což není jasné v definici, DAL je vrstva přístupu k datům, nikoli vrstva úložiště dat, takže databáze nemůže být touto vrstvou. Role SQLHelperu je snížit opakující se kódování a zlepšit efektivitu programování, takže pokud jsem zvyklý starat se o efektivitu nebo používat zdroj dat mimo databázi, mohu SQLHelper, část, kterou lze kdykoli zahodit, zahodit – jak se může stát vrstvou třívrstvé architektury.
Lze jej definovat následovně: kód související s operacemi datových zdrojů by měl být umístěn do vrstvy přístupu k datům, která patří do vrstvy přístupu k datům
5、IUserDAL
Rozhraní pro datovou přístupovou vrstvu, to je další nepotřebná věc, protože Petshop ji přináší i ClassFactory s tím, takže některé projekty dělají tyto dvě věci bez ohledu na to, zda potřebují podporovat více datových zdrojů, a některé dokonce nestaví ClassFactory, ale pouze IDAL, a pak "IUserDAL iUserDal = nový UserDAL(); Nevím, co to znamená. Tohle je úplně tygr, ne odpůrce psa.
Mnoho lidí zde má mylnou představu, že existuje takový vztah: BLL?àIDAL?àDAL, myslí si, že IDAL funguje jako most mezi BLL a DAL, a BLL volá DAL přes IDAL. Ale realita je taková, že i když to napíšete takto: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Při spuštění "iUserDal.SelectUsers()" se skutečně vykonává instance UserDAL, nikoli instance IUserDAL, takže pozice IDAL ve třetí vrstvě souvisí s úrovní DAL.
Výše uvedeným úvodem je hierarchie tříúrovňové architektury v podstatě vysvětlena. Ve skutečnosti mám způsob, jak posoudit, zda je třívrstvá architektura standardní, tedy že úplné nahrazení kterékoli ze tří vrstev neovlivní ostatní dvě vrstvy, a taková struktura v podstatě splňuje třívrstvý standard (i když je ^_^ složitější ji implementovat). Například pokud změníte projekt z B/S na C/S (nebo naopak), pak BLL a DAL nemusí být měnitelné kromě UI; Nebo změnit SQLServer na Oracle, prostě nahradit SQLServerDAL za OracleDAL, žádné další operace nejsou potřeba atd. Původně jsem chtěl do článku přidat nějaký konkrétní kód, ale nemyslím si, že je to nutné, pokud to budete považovat za nutné, přidám ho.
Shrnutí: Nemyslete si, že vrstva je zbytečná jen proto, že je pro vás k ničemu, nebo je obzvlášť jednoduchá na implementaci, nebo ji opustit, nebo použít pro jiné účely. Pokud jsou vrstvy provedeny, bez ohledu na počet vrstev, musí mít každá vrstva jasný účel a funkční realizaci a neměla by být ovlivněna samotným procesem, což vede k tomu, že stejný typ souboru bude umístěn v různých vrstvách. Nenech stejnou vrstvu implementovat různé funkce. |
Zveřejněno 07.05.2015 10:53:35
|
|
|
