BLL är affärslogikskiktet
DAL står Data Access Layer
Tre-nivåarkitektur av ASP.NET (DAL, BLL, UI)
Grafiken representerar en trelagersstruktur. Webben är USL-lagret
Web –> BLL –> Al
| | |
| V |
+–> modell <—+
1. Trenivåarkitektur
1. Presentationslagret (USL): Det representerar främst WEB-metoden, men kan också uttryckas som WINFORM-läge. Om logiklagret är ganska robust och väletablerat kommer det att fungera perfekt oavsett hur prestandalagret definieras och ändras.
2. Affärslogiklager (BLL): främst för specifika problem kan det också förstås som datalagerets funktion och den logiska bearbetningen av dataverksamhet. Om datalagret är byggstenarna, är logiklagret byggstenen.
3. Dataåtkomstlager (DAL): Det är huvudsakligen operationslagret för originaldata (i form av en databas eller textfil eller annan form av lagring av data), snarare än originaldata, det vill säga datans drift, inte databasen, specifikt affärslogikskidret eller presentationslagret
Tillhandahållande av datatjänster.
2. Specifik skillnad
1. Presentationslager: accepterar huvudsakligen användarens förfrågan och returnerar data, vilket ger klienten tillgång till applikationen.
2. Affärslogiklager: huvudsakligen ansvarigt för datalagrets drift, det vill säga kombinationen av vissa datalagersoperationer.
3. Dataåtkomstlagret: Det beror främst på om ditt datalager innehåller logisk bearbetning, faktiskt utför dess funktioner främst olika operationer på datafilen och behöver inte oroa sig för andra operationer.
3. Sammanfattning
Trelagersstrukturen är en strikt hierarkisk metod, det vill säga dataåtkomstlagret (DAL) kan endast nås av affärslogikskiktet (BLL), och affärslogikskiktet kan endast nås av presentationslagret (USL). Vissa trelagersstrukturer lägger också till andra lager som Fabrik och Modell, vilka faktiskt är en utvidgning och applikation baserad på dessa tre lager.
Ett enkelt trelagersprogram inkluderar vanligtvis flera projekt av DAL BLL WEB MODEL, och deras ömsesidiga referenser är följande
1) WEB-referenser BLL, Modell
2) BLL refererar till DAL, modell
3) DAL refererar till modellen
4) Modellen har inga referenser
När det gäller tre-nivåarkitekturen vet alla att det är prestandalagret (UI), affärslogikskiktet (BLL) och dataåtkomstlagret (DAL), och det finns många sätt att dela upp varje lager. Men hur man skriver den specifika koden och vilket lager filerna räknas i är oklart. Följande är ett enkelt exempel för att leda dig till att öva ett trelagersarkitekturprojekt, detta exempel har bara en funktion, nämligen enkel hantering av användare.
Skapa först en tom lösning och lägg till följande objekt och filer
1. Lägg till ett ASP.NET Web Application-projekt, namnge det UI och skapa en ny Web Form-fil User.aspx (inklusive User.aspx.cs)
2. Lägg till ett ClassLibrary-projekt, döp det till BLL och skapa en ny Class-fil UserBLL.cs
3. Lägg till ett ClassLibrary-projekt, döp det till DAL och skapa en ny Class-fil UserDAL.cs. Lägg till en SQLHelper-referens. (Detta är Microsofts dataåtkomstklass, eller så kan du skriva all dataåtkomstkod direkt.) Jag brukar använda DataAccessHelper-klassen som jag skriver).
4. Lägg till ett ClassLibrary-projekt, döp det till Model och skapa en ny klasstypfil UserModel.cs
5. Lägg till ett ClassLibrary-projekt, döp det till IDAL och skapa en ny Interface-fil IUserDAL.cs
6. Lägg till ett ClassLibrary-projekt och döp det till ClassFactory
Jag tror att du har sett att detta inte skiljer sig från Petshops exempel, och det är enklare, eftersom jag också lär mig trelagersarkitekturen genom Petshop. Dock kan vissa vänner vara vaga om nivån på dessa projekt och relationen mellan dem, här är en förklaring av dem en efter en:
1. User.aspx och User.aspx.cs
Både dokumenten (och de objekt som filen tillhör, liksom nedan, kommer inte att upprepas) ingår i presentationslagret. User.aspx är lättare att förstå eftersom det är en visningssida. User.aspx.cs vissa tycker att det inte borde räknas, utan bör ingå i affärslogikslagret. Om du inte gör lager-på-lager är det inget problem att låta User.aspx.cs hantera affärslogik och ens driva databasen, men om du gör lager-på-lager bör detta inte göras. I en hierarkisk struktur bör User.aspx.cs endast hantera innehåll relaterat till visning, och inget annat ska täckas.
Till exempel, om vi implementerar funktionen att visa användare i form av en lista, utförs arbetet med att extrahera information av BLL, och efter att UI:t (i detta fall är det User.aspx.cs) anropar BLL för att hämta UserInfo, är det bundet till datakontrollen i User.aspx genom-koden för att realisera visningen av listan. I denna process spelar det User.aspx.cs ingen roll i UI:t, det används endast för att skicka data, och eftersom det mesta av den faktiska kodningen är implementerad så här, anser vissa att User.aspx.cs inte ska räknas som UI, utan bör slås ihop med BLL för logisk bearbetning. Vidare infördes ett nytt krav att lägga till en ikon framför varje användare för att tydligt representera användarens kön, och för dem under 18 år representerades den av en barnikon. Förverkligandet av detta krav är User.aspx.cs sin tur, och i detta fall User.aspx.cs det har en verklig användning.
2、NewBLL.cs
Lägg till följande metoder:
publik IList GetUsers(): Returnerar en lista över all användarinformation
publik UserInfo GetUser(int UserId): Returnerar uppgifterna för den angivna användaren
publik bool AddUser(UserInfo User): Tillagd användarinformation
publik bool ChangeUser(UserInfo User): Uppdaterar användarinformation
public void RemoveUser(int UserId): Tar bort användarinformation
Denna fil tillhör affärslogikskiktet och är dedikerad för att hantera operationer relaterade till affärslogik. Många kanske tror att det enda syftet med detta lager är att vidarebefordra data från prestandalagret till datalagret. Det finns verkligen många sådana fall, men detta kan bara betyda att projektet är relativt enkelt, eller att relationen mellan projektet och verksamheten inte är nära integrerad (som den nuvarande populära MIS), så affärsskiktet har inget att göra och bara spelar en vidarebefordrande roll. Men detta betyder inte att affärslagret är utbytbart, eftersom projektet växer eller det finns fler affärsrelationer kommer affärslagret att spegla dess roll.
Det mest sannolika felet här är att tilldela dataoperationkoden till affärslogiklagret och databasen som dataåtkomstlager.
Till exempel tycker vissa vänner att BLL-lagret inte är meningsfullt, men de laddar bara upp DAL-data och vidarebefordrar det till gränssnittet utan någon bearbetning. Titta på det här exemplet
BLL-lagret
SelectUser(UserInfo userInfo) hämtar användaruppgifterna baserat på användarnamnet eller e-postadressen som kommer in.
IsExist(UserInfo userInfo) avgör om det angivna användarnamnet eller e-postadressen finns.
Då tillhandahåller DAL också motsvarande metod för BLL-anropet
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
På så sätt spelar BLL endast en transmissionsroll.
Men om du gör det:
BRA. IsExist (Userinfo userinfo)
{
UerInfo-användare = DAL. SelectUser(User);
återvända (userInfo.Id != null);
}
Då behöver DAL inte implementera IsExist()-metoden, och det finns logisk bearbetningskod i BLL.
3、UserModel.cs
Entitet, det här kan du tro att det inte är lätt att stratifiera. Inklusive mig själv förstod jag det så här: UI?àModel?àBLL?àModel?àDAL, så det tros att modellen fungerar som en brygga för dataöverföring mellan lagren. Men här tänker vi inte på saker enkelt, utan på komplexitet.
Vad är modell? Det är inget! Det är utbytbart i en trestegsarkitektur. Det är faktiskt det mest grundläggande inom objektorienterad programmering: klasser. Ett bord är en klass, en news är också en klass, int, string, doublie, etc. är också klasser, det är bara en klass.
På detta sätt är modellens position i trelagersarkitekturen densamma som statusen för variabler som int och sträng, och den har inget annat syfte, den används endast för datalagring, men lagrar komplex data. Därför, om objekten i ditt projekt är mycket enkla, kan du direkt skicka flera parametrar utan modell för att skapa en trelagersarkitektur.
Så varför behöver du en modell, och vilka är dess fördelar? Följande är vad som dyker upp i tankarna när man funderar på en fråga, insatt här:
Kan modellen spela en större roll i överföringen av parametrar på varje lager?
När du skickar parametrar mellan lager kan du göra följande:
AddUser(userId,userName,userPassword,...,)
Det kan också vara så här:
AddUser(userInfo)
Vilken av dessa två metoder är bäst? Vid en första anblick måste det vara den andra mycket bättre.
När ska man skicka parametrar mellan lager med normala variabeltyper (int, string, guid, double), och vad ska man skicka med Model? Följande metoder:
SelectUser(int UserId)
SelectUserByName(stränganvändarnamn)
SelectUserByName(stränganvändarnamn, stränglösenord)
SelectUserByEmail (sträng e-post)
SelectUserByEmail(sträng e-post, stränglösenord)
Den kan sammanfattas som:
SelectUser(userId)
SelectUser(användare)
Här använder vi användarmodellobjektet för att inkludera fyra kombinationsläge av användarnamn, lösenord och e-post. UserId kan också slås ihop med user, men andra BLL i projektet implementerar gränssnitt med id-parametrar, så detta objekt behålls också.
userInfo skickas vidare, så hur man hanterar det, detta måste vara i ordning, det finns en specifik kod att bestämma.
Här behandlas det i denna ordning
Först, se om du har både användarnamn och lösenord, sedan om du har både e-post och lösenord, sedan om du har användarnamn, och sedan om du har e-post. Bearbetas sekventiellt.
På så sätt, om ett nytt innehåll läggs till i framtiden, medlemskortet (numret), finns det inget behov av att ändra gränssnittet, utan bara lägga till stöd för nummer i DAL-koden och sedan prestanda och bearbetning av medlemskortets innehåll i förgrunden.
4、UserDAL.cs
publik IList SelectUsers(): Returnerar en lista över all användarinformation
publik UserInfo SelectUser(int UserId): Returnerar den betrodda informationen för den angivna användaren
publik bool InsertUser(UserInfo User): Tillagd användarinformation
publik bool UpdateUser(UserInfo User): Uppdaterar användarinformation
public void DeleteUser(int UserId): Tar bort användarinformation
Det många som oftast inte kan lista ut är dataåtkomstlagret, vilken del anses vara dataåtkomstlagret? Vissa tror att databasen är dataåtkomstlagret, vilket inte är tydligt i definitionen, DAL är dataåtkomstlagret snarare än datalagringslagret, så databasen kan inte vara detta lager. SQLHelpers roll är att minska repetitiv kodning och förbättra kodningseffektiviteten, så om jag är van vid att bry mig om effektivitet eller använda en datakälla som inte är databas, kan jag kasta bort SQLHelper, en del som kan kasseras när som helst, hur kan den bli ett lager i trelagersarkitekturen.
Den kan definieras på följande sätt: koden som rör datakälloperationer ska placeras i dataåtkomstlagret, som tillhör dataåtkomstlagret
5、IUserDAL
Dataåtkomstlagrets gränssnitt, detta är en annan dispensär sak, eftersom Petshop tar med sig det och ClassFactory factory, så vissa projekt gör dessa två saker oavsett om de behöver stödja flera datakällor eller inte, och vissa bygger inte ens ClassFactory utan bara IDAL, och sedan "IUserDAL iUserDal = ny UserDAL(); Jag vet inte vad det betyder. Det här är helt klart en tiger och inte en hundfientlig hund.
Många har en missuppfattning här, nämligen att det finns ett sådant samband: BLL?àIDAL?àDAL, i tron att IDAL fungerar som en brygga mellan BLL och DAL, och BLL kallar DAL via IDAL. Men verkligheten är att även om du kodar det så här: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); När man kör "iUserDal.SelectUsers()" är det faktiskt UserDAL-instansen som körs, inte IUserDAL-instansen, så positionen för IDAL i det tredje lagret är relaterad till DAL-nivån.
Genom ovanstående introduktion förklaras hierarkin i trestegsarkitekturen i grunden. Faktum är att jag har ett sätt att avgöra om trelagersarkitekturen är standard, det vill säga att en fullständig ersättning av något av de tre lagren inte påverkar de andra två lagren, och en sådan struktur uppfyller i princip trelagersstandarden (även om den är svårare ^_^ att implementera). Till exempel, om du ändrar projektet från B/S till C/S (eller tvärtom), behöver BLL och DAL inte ändras förutom UI; Eller byt SQLServer till Oracle, byt bara ut SQLServerDAL mot OracleDAL, inga andra operationer krävs, osv. Jag ville ursprungligen lägga till specifik kod i artikeln, men jag tycker inte att det är nödvändigt, om du tycker det är nödvändigt lägger jag till det.
Sammanfattning: Tänk inte att ett lager är onödigt bara för att det är värdelöst för dig, eller särskilt enkelt att implementera, eller överge det, eller använda det för andra ändamål. Så länge lagren genomförs, oavsett hur många lager det finns, måste varje lager ha ett tydligt syfte och funktionsrealisering, och bör inte påverkas av själva processen, vilket resulterar i att samma typ av fil placeras i olika lager. Låt inte samma lager implementera olika funktioner. |
Publicerad på 2015-05-07 10:53:35
|
|
|
