BLL er Business Logic Layer
DAL er Data Access Layer
Tre-lags arkitektur af ASP.NET (DAL, BLL, UI)
Grafikken repræsenterer en tre-lags struktur. Webben er USL-laget
Web –> BLL –> Al
| | |
| V |
+–> model <—+
1. Tre-lags arkitektur
1. Præsentationslag (USL): Det repræsenterer primært WEB-metoden, men kan også udtrykkes som WINFORM-tilstand. Hvis logiklaget er ret robust og veletableret, vil det fungere perfekt uanset hvordan ydelseslaget defineres og ændres.
2. Forretningslogiklag (BLL): hovedsageligt for specifikke problemer kan det også forstås som driften af datalaget og den logiske behandling af dataforretning. Hvis datalaget er byggestenene, så er logiklaget byggestenen.
3. Dataadgangslag (DAL): Det er hovedsageligt operationslaget for de oprindelige data (i form af en database, tekstfil eller anden form for lagring af data), snarere end de oprindelige data, altså dataens drift, ikke databasen, specifikt forretningslogiklaget eller præsentationslaget
Levering af datatjenester.
2. Specifik sondring
1. Præsentationslag: modtager hovedsageligt brugerens anmodning og returnerer data, hvilket giver klienten adgang til applikationen.
2. Forretningslogiklag: hovedsageligt ansvarlig for driften af datalaget, det vil sige kombinationen af nogle datalagsoperationer.
3. Dataadgangslag: Det afhænger hovedsageligt af, om dit datalag indeholder logisk behandling; faktisk udfører dets funktioner hovedsageligt forskellige operationer på datafilen og behøver ikke bekymre sig om andre operationer.
3. Resumé
Tre-lags strukturen er en streng hierarkisk tilgang, det vil sige, at dataadgangslaget (DAL) kun kan tilgås af forretningslogiklaget (BLL), og forretningslogiklaget kun kan tilgås af præsentationslaget (USL). Nogle tre-lags strukturer tilføjer også andre lag som Fabrik og Model, som faktisk er en udvidelse og anvendelse baseret på disse tre lag.
Et simpelt tre-lags program inkluderer generelt flere projekter af DAL BLL WEB-modellen, og deres gensidige referencer er som følger
1) WEB-referencer BLL, model
2) BLL refererer til DAL, Model
3) DAL refererer til modellen
4) Modellen har ingen kildehenvisninger
Når det kommer til tre-lags arkitekturen, ved alle, at det er performance-laget (UI), business logic layer (BLL) og data access layer (DAL), og der er mange måder at opdele hvert lag på. Men hvordan man skriver den specifikke kode, og hvilket lag filerne tælles i, er uklart. Følgende er et simpelt eksempel, der kan føre dig til at øve et tre-lags arkitekturprojekt; dette eksempel har kun én funktion, nemlig simpel brugerstyring.
Først skal du oprette en tom løsning og tilføje følgende elementer og filer
1. Tilføj et ASP.NET Web Application-projekt, navngiv det UI, og opret en ny Web Form-fil User.aspx (inklusive User.aspx.cs)
2. Tilføj et ClassLibrary-projekt, navngiv det BLL og opret en ny Class-fil UserBLL.cs
3. Tilføj et ClassLibrary-projekt, navngiv det DAL, og skab en ny Class-fil UserDAL.cs. Tilføj en SQLHelper-reference. (Dette er Microsofts dataadgangsklasse, eller du kan skrive al dataadgangskoden direkte.) Jeg bruger normalt DataAccessHelper-klassen, som jeg skriver).
4. Tilføj et ClassLibrary-projekt, navngiv det Model og opret en ny Class-type fil UserModel.cs
5. Tilføj et ClassLibrary-projekt, navngiv det IDAL og opret en ny Interface-fil IUserDAL.cs
6. Tilføj et ClassLibrary-projekt og kald det ClassFactory
Jeg tror, du har set, at dette ikke adskiller sig fra Petshops eksempel, og det er enklere, fordi jeg også lærer tre-lags arkitekturen gennem Petshop. Dog kan nogle venner være vage omkring omfanget af disse projekter og forholdet mellem dem, her er en forklaring på dem én ad gangen:
1. User.aspx og User.aspx.cs
Både dokumenter (og de elementer, filen hører til, samt nedenfor, vil ikke blive gentaget) er en del af præsentationslaget. User.aspx er lettere at forstå, fordi det er en visningsside. User.aspx.cs nogle mener, at det ikke bør tælles, men bør inkluderes i forretningslogiklaget. Hvis du ikke laver lagdeling, er der ikke noget problem i at lade User.aspx.cs håndtere forretningslogik og endda betjene databasen, men hvis du laver lagdeling, bør det ikke gøres. I en hierarkisk struktur bør User.aspx.cs kun omhandle indhold relateret til visning, og intet andet bør dækkes.
For eksempel, hvis vi implementerer funktionen med at vise brugere i form af en liste, udføres arbejdet med at udtrække information af BLL, og efter at UI'en (i dette tilfælde User.aspx.cs kalder BLL for at hente UserInfo, er den bundet til datakontrollen af User.aspx gennem koden for at realisere visningen af listen. I denne proces spiller det User.aspx.cs ikke en rolle i UI'en, det bruges kun til at overføre data, og fordi det meste af selve kodningen er implementeret sådan, mener nogle, at User.aspx.cs ikke bør tælles som UI, men bør slås sammen med BLL for logisk behandling. Yderligere blev der fremsat et nyt krav om at tilføje et ikon foran hver bruger for levende at repræsentere brugerens køn, og for dem under 18 år blev det repræsenteret af et børneikon. Realiseringen af dette krav er User.aspx.cs vendepunkt, og i dette tilfælde User.aspx.cs det en reel anvendelse.
2、NewBLL.cs
Tilføj følgende metoder:
offentlig IList GetUsers(): Returnerer en liste over al brugerinformation
offentlig UserInfo GetUser(int UserId): Returnerer oplysningerne om den specificerede bruger
public bool AddUser(UserInfo User): Tilføjet brugerinformation
offentlig bool ChangeUser(UserInfo User): Opdaterer brugerinformation
public void RemoveUser(int UserId): Fjerner brugerinformation
Denne fil tilhører forretningslogiklaget og er dedikeret til håndtering af operationer relateret til forretningslogik. Mange tror måske, at det eneste formål med dette lag er at videresende data fra ydelseslaget til datalaget. Der findes ganske vist mange sådanne tilfælde, men det kan kun betyde, at projektet er relativt simpelt, eller at forholdet mellem selve projektet og virksomheden ikke er tæt integreret (som den nuværende populære MIS), så forretningslaget ikke har noget at gøre og kun spiller en videresendende rolle. Men det betyder ikke, at forretningslaget er udskifteligt; efterhånden som projektet vokser, eller der opstår flere forretningsforbindelser, vil forretningslaget afspejle sin rolle.
Den mest sandsynlige fejl her er at tildele dataoperationskoden til forretningslogiklaget og databasen som dataadgangslag.
For eksempel mener nogle venner, at BLL-laget ikke er meningsfuldt, men de uploader bare DAL-dataene og videresender dem til UI'en uden nogen behandling. Tag et kig på dette eksempel
BLL lag
SelectUser(UserInfo userInfo) får brugeroplysningerne baseret på brugernavnet eller den e-mail, der kommer ind.
IsExist(UserInfo userInfo) afgør, om det angivne brugernavn eller e-mail eksisterer.
Så giver DAL også den tilsvarende metode for BLL-kaldet
SelectUser(UserInfo userInfo)
IsExist(UserInfo brugerInfo)
På denne måde spiller BLL kun en transmissionsrolle.
Men hvis du gør:
BLL. IsExist (Userinfo userinfo)
{
UerInfo-bruger = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Så behøver DAL ikke implementere IsExist()-metoden, og der findes logisk behandlingskode i BLL.
3、UserModel.cs
Entitet, denne ting, du tænker måske, det er ikke let at stratificere. Inklusive mig selv forstod jeg det således: UI?àModel?àBLL?àModel?àDAL, så det antages, at modellen fungerer som en bro for datatransmission mellem lagene. Men her tænker vi ikke på ting simple, men på kompleksitet.
Hvad er model? Det er ingenting! Det er udskifteligt i en tre-niveaus arkitektur. Det er faktisk det mest grundlæggende i objektorienteret programmering: klasser. Et bord er en klasse, en nyhed er også en klasse, int, string, doublie osv. er også klasser, det er bare en klasse.
På denne måde er modellens position i tre-lags arkitekturen den samme som status for variabler som int og streng, og den har ikke andet formål; den bruges kun til datalagring, men den gemmer komplekse data. Derfor, hvis objekterne i dit projekt er meget simple, kan du direkte sende flere parametre uden en model for at skabe en tre-lags arkitektur.
Så hvorfor har du brug for en model, og hvad er dens fordele? Følgende er det, der falder mig ind, når man tænker over et spørgsmål, indsat her:
Kan modellen spille en større rolle i overleveringen af parametre på hvert lag?
Når du sender parametre mellem lag, kan du gøre følgende:
AddUser(userId,brugerNavn,brugerPassword,...,)
Det kan også være sådan her:
AddUser(userInfo)
Hvilken af disse to metoder er bedst? Ved første øjekast må det være den anden meget bedre.
Hvornår skal man sende parametre mellem lag med normale variabeltyper (int, string, guid, double), og hvad skal man sende med Model? Følgende metoder:
SelectUser(int UserId)
SelectUserByName(streng-brugernavn)
SelectUserByName(strengbrugernavn, strengadgangskode)
SelectUserByEmail(streng email)
SelectUserByEmail(streng email, string password)
Det kan opsummeres som:
SelectUser(userId)
SelectUser(bruger)
Her bruger vi brugermodelobjektet til at inkludere fire kombinationstilstande: brugernavn, adgangskode og e-mail. UserId kan også slås sammen med bruger, men andre BLL i projektet implementerer grænseflader med id-parametre, så dette element bevares også.
userInfo bliver overgivet, så hvordan man håndterer det, skal det være i rækkefølge, der er en specifik kode at beslutte.
Her behandles det i denne rækkefølge
Først, se om du har både brugernavn og adgangskode, så om du har både e-mail og adgangskode, så om du har brugernavn, og så om du har e-mail. Behandlet sekventielt.
På denne måde, hvis et nyt indhold tilføjes i fremtiden, medlemskortet (nummeret), er der ikke behov for at ændre grænsefladen, blot at tilføje understøttelse af nummer i DAL-koden og derefter tilføje ydeevne og behandling af medlemskortets indhold i forgrunden.
4、UserDAL.cs
offentlig IList SelectUsers(): Returnerer en liste over alle brugeroplysninger
public UserInfo SelectUser(int UserId): Returnerer den betroede information om den angivne bruger
offentlig bog: IndsætterBruger(BrugerInfo Bruger): Tilføjet brugerinformation
offentlig bool UpdateUser(UserInfo User): Opdaterer brugerinformation
public void DeleteUser(int UserId): Fjerner brugerinformation
Det, mange ikke kan finde ud af, er dataadgangslaget, hvilken del der betragtes som dataadgangslaget? Nogle mener, at databasen er dataadgangslaget, hvilket ikke er klart i definitionen, DAL er dataadgangslaget i stedet for datalagringslaget, så databasen kan ikke være dette lag. SQLHelpers rolle er at reducere gentagen kodning og forbedre kodningseffektiviteten, så hvis jeg er vant til at gå op i effektivitet eller bruge en ikke-databasebaseret datakilde, kan jeg kassere SQLHelper, en del der kan kasseres efter behag – hvordan kan det blive et lag i tre-lags arkitekturen.
Den kan defineres som følger: koden relateret til datakildeoperationer bør placeres i dataadgangslaget, som hører til dataadgangslaget
5、IUserDAL
Dataadgangslagsgrænsefladen, dette er endnu en udskiftelig ting, fordi Petshop bringer det og ClassFactory factory med sig, så nogle projekter gør disse to ting uanset om de skal understøtte flere datakilder eller ej, og nogle bygger endda ikke ClassFactory, men kun IDAL, og så "IUserDAL iUserDal = ny UserDAL(); Jeg ved ikke, hvad meningen er. Dette er fuldstændig en tiger og ikke en anti-hund.
Mange har en misforståelse her, nemlig at der findes et sådant forhold: BLL?àIDAL?àDAL, idet de tror, at IDAL fungerer som en bro mellem BLL og DAL, og BLL kalder DAL gennem IDAL. Men realiteten er, at selv hvis du koder det på denne måde: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Når man kører "iUserDal.SelectUsers()", er det faktisk UserDAL-instansen, der udføres, ikke IUserDAL-instansen, så positionen af IDAL i det tredje lag er relateret til DAL-niveauet.
Gennem ovenstående introduktion forklares hierarkiet for den tre-lags arkitektur grundlæggende. Faktisk har jeg en måde at vurdere, om tre-lags arkitekturen er standard, det vil sige, at en fuldstændig udskiftning af et af de tre lag ikke vil påvirke de to andre lag, og en sådan struktur opfylder grundlæggende tre-lags standarden (selvom det er sværere ^_^ at implementere). For eksempel, hvis du ændrer projektet fra B/S til C/S (eller omvendt), behøver BLL og DAL kun ændres i UI; Eller skift SQLServer til Oracle, bare erstat SQLServerDAL til OracleDAL, ingen andre operationer er nødvendige osv. Jeg ville oprindeligt tilføje noget specifik kode til artiklen, men jeg synes ikke, det er nødvendigt; hvis du synes, det er nødvendigt, vil jeg tilføje det.
Resumé: Tro ikke, at et lag er unødvendigt bare fordi det er ubrugeligt for dig, eller det er særligt simpelt at implementere, eller opgive det, eller bruge det til andre formål. Så længe lagene udføres, uanset hvor mange lag der er, skal hvert lag have et klart formål og en funktion, og det bør ikke påvirkes af selve processen, hvilket resulterer i, at samme type fil findes i forskellige lag. Lad ikke det samme lag implementere forskellige funktioner. |
Opslået på 07/05/2015 10.53.35
|
|
|
