BLL er forretningslogikklaget
DAL er Data Access Layer
Tre-nivås arkitektur av ASP.NET (DAL, BLL, UI)
Grafikken representerer en tre-lags struktur. Nettet er USL-laget
Web –> BLL –> Dal
| | |
| V |
+–> modell <—+
1. Tre-lags arkitektur
1. Presentasjonslag (USL): Det representerer hovedsakelig WEB-metoden, men kan også uttrykkes som WINFORM-modus. Hvis logikklaget er ganske robust og godt etablert, vil det fungere perfekt uansett hvordan ytelseslaget defineres og endres.
2. Forretningslogikklag (BLL): hovedsakelig for spesifikke problemer kan det også forstås som driften av datalaget og den logiske behandlingen av datavirksomheten. Hvis datalaget er byggesteinene, er logikklaget byggesteinen.
3. Datatilgangslag (DAL): Det er hovedsakelig operasjonslaget for de opprinnelige dataene (i form av en database, tekstfil eller annen form for lagring av data), snarere enn de opprinnelige dataene, altså operasjonen av dataene, ikke databasen, spesifikt forretningslogikklaget eller presentasjonslaget
Levering av datatjenester.
2. Spesifikk distinksjon
1. Presentasjonslag: aksepterer hovedsakelig brukerens forespørsel, og returnerer data, slik at klienten får tilgang til applikasjonen.
2. Forretningslogikklag: hovedsakelig ansvarlig for driften av datalaget, det vil si kombinasjonen av noen datalagsoperasjoner.
3. Datatilgangslag: Det avhenger hovedsakelig av om datalaget ditt inneholder logisk behandling, faktisk utfører funksjonene hovedsakelig ulike operasjoner på datafilen, og du trenger ikke bekymre deg for andre operasjoner.
3. Sammendrag
Trelagsstrukturen er en streng hierarkisk tilnærming, det vil si at dataaksesslaget (DAL) kun kan nås av forretningslogikklaget (BLL), og forretningslogikklaget kun kan nås av presentasjonslaget (USL). Noen tre-lags strukturer legger også til andre lag som Fabrikk og Modell, som faktisk er en utvidelse og applikasjon basert på disse tre lagene.
Et enkelt tre-lags program inkluderer vanligvis flere prosjekter av DAL BLL WEB Model, og deres gjensidige referanser er som følger
1) WEB-referanser BLL, modell
2) BLL refererer til DAL, modell
3) DAL refererer til modellen
4) Modellen har ingen referanser
Når det gjelder tre-lags arkitekturen, vet alle at det er ytelseslaget (UI), forretningslogikklaget (BLL) og datatilgangslaget (DAL), og det finnes mange måter å dele opp hvert lag på. Men hvordan man skriver den spesifikke koden og hvilket lag filene telles i, er uklart. Følgende er et enkelt eksempel for å lede deg til å praktisere et tre-lags arkitekturprosjekt, dette eksempelet har bare én funksjon, nemlig enkel brukerstyring.
Først, lag en tom løsning og legg til følgende elementer og filer
1. Legg til et ASP.NET Web Application-prosjekt, kall det UI, og lag en ny Web Form-fil User.aspx (inkludert User.aspx.cs)
2. Legg til et ClassLibrary-prosjekt, gi det navnet BLL, og lag en ny Class-fil UserBLL.cs
3. Legg til et ClassLibrary-prosjekt, kall det DAL, og lag en ny Class-fil UserDAL.cs. Legg til en SQLHelper-referanse. (Dette er Microsofts datatilgangsklasse, eller du kan skrive all datatilgangskoden direkte.) Jeg bruker vanligvis DataAccessHelper-klassen som jeg skriver).
4. Legg til et ClassLibrary-prosjekt, kall det Model, og lag en ny Class-type fil UserModel.cs
5. Legg til et ClassLibrary-prosjekt, kall det IDAL, og lag en ny Interface-fil IUserDAL.cs
6. Legg til et ClassLibrary-prosjekt og kall det ClassFactory.
Jeg tror du har sett at dette ikke er annerledes enn Petshops eksempel, og det er enklere, fordi jeg også lærer tre-lags arkitekturen gjennom Petshop. Noen venner kan imidlertid være vage om omfanget av disse prosjektene og forholdet mellom dem, her er en forklaring på dem én etter én:
1. User.aspx og User.aspx.cs
Begge dokumentene (og elementene filen tilhører, samt under, vil ikke bli gjentatt) er en del av presentasjonslaget. User.aspx er lettere å forstå fordi det er en visningsside. User.aspx.cs noen mener at det ikke bør telles, men bør inkluderes i forretningslogikk-laget. Hvis du ikke gjør lagdeling, er det ikke noe problem å la User.aspx.cs håndtere forretningslogikken og til og med drifte databasen, men hvis du gjør lagdeling, bør ikke dette gjøres. I en hierarkisk struktur bør User.aspx.cs kun omhandle innhold relatert til visning, og ingenting annet skal dekkes.
For eksempel, hvis vi implementerer funksjonen med å vise brukere i form av en liste, utføres arbeidet med å hente ut informasjon av BLL, og etter at UI-en (i dette tilfellet er det User.aspx.cs) kaller BLL for å hente UserInfo, er den bundet til datakontrollen til User.aspx gjennom koden for å realisere visningen av listen. I denne prosessen User.aspx.cs det ikke spiller noen rolle i UI-en, brukes det kun til å sende data, og fordi mesteparten av selve koden er implementert slik, mener noen at User.aspx.cs ikke bør regnes som UI, men bør slås sammen med BLL for logisk behandling. Videre ble det innført et nytt krav om å legge til et ikon foran hver bruker for å tydelig representere brukerens kjønn, og for de under 18 år ble det representert med et barneikon. Realiseringen av dette kravet er User.aspx.cs vending, og i dette tilfellet User.aspx.cs det en reell nytte.
2、NewBLL.cs
Legg til følgende metoder:
offentlig IList GetUsers(): Returnerer en liste over all brukerinformasjon
offentlig UserInfo GetUser(int UserId): Returnerer detaljene til den angitte brukeren
offentlig bool AddUser(UserInfo User): Lagt til brukerinformasjon
offentlig bool ChangeUser(UserInfo User): Oppdaterer brukerinformasjon
public void RemoveUser(int UserId): Fjerner brukerinformasjon
Denne filen tilhører forretningslogikklaget og er dedikert til å håndtere operasjoner relatert til forretningslogikk. Mange tror kanskje at det eneste formålet med dette laget er å videresende data fra ytelseslaget til datalaget. Det finnes faktisk mange slike tilfeller, men dette kan bare bety at prosjektet er relativt enkelt, eller at forholdet mellom prosjektet selv og virksomheten ikke er tett integrert (slik som den populære MIS-en i dag), så forretningslaget har ingenting å gjøre, og kun spiller en videresendende rolle. Men dette betyr ikke at forretningslaget er overflødig, for etter hvert som prosjektet vokser, eller det oppstår flere forretningsforbindelser, vil forretningslaget reflektere sin rolle.
Den mest sannsynlige feilen her er å tildele dataoperasjonskoden til forretningslogikklaget og databasen som datatilgangslaget.
For eksempel mener noen venner at BLL-laget ikke er meningsfullt, men de bare laster opp DAL-dataene og videresender dem til UI-en uten noen behandling. Ta en titt på dette eksempelet
BLL-laget
SelectUser(UserInfo userInfo) henter brukerdetaljene basert på brukernavnet eller e-posten som kommer inn.
IsExist(UserInfo userInfo) avgjør om det angitte brukernavnet eller e-posten eksisterer.
Da gir DAL også den tilsvarende metoden for BLL-kallet
SelectUser(UserInfo userInfo)
IsExist(BrukerInfo brukerInfo)
På denne måten spiller BLL kun en overføringsrolle.
Men hvis du gjør det:
BLL. IsExist (brukerinfo brukerinfo)
{
UerInfo-bruker = DAL. SelectUser(User);
returnere (userInfo.Id != null);
}
Da trenger ikke DAL å implementere IsExist()-metoden, og det finnes logisk prosesseringskode i BLL.
3、UserModel.cs
Entitet, denne tingen, du tror kanskje det ikke er lett å stratifisere. Inkludert meg selv forstod jeg det slik: UI?àModel?àBLL?àModel?àDAL, så det antas at modellen fungerer som en bro for dataoverføring mellom lagene. Men her tenker vi ikke på ting enkelt, men på kompleksitet.
Hva er Model? Det er ingenting! Det er overflødig i en tre-nivås arkitektur. Det er faktisk det mest grunnleggende i objektorientert programmering: klasser. Et bord er en klasse, en news er også en klasse, int, string, doublie, osv. er også klasser, det er bare en klasse.
På denne måten er modellens posisjon i trelagsarkitekturen den samme som statusen til variabler som int og streng, og den har ingen annen funksjon; den brukes kun til datalagring, men lagrer komplekse data. Derfor, hvis objektene i prosjektet ditt er veldig enkle, kan du direkte sende flere parametere uten modell for å lage en tre-lags arkitektur.
Så hvorfor trenger du en modell, og hva er fordelene dens? Følgende er det som faller meg inn når man tenker på et spørsmål, satt inn her:
Kan modellen spille en større rolle i overføringen av parametere på hvert lag?
Når du sender parametere mellom lagene, kan du gjøre følgende:
AddUser(brukerId, brukerNavn, brukerPassord,...,)
Det kan også være slik:
AddUser(userInfo)
Hvilken av disse to metodene er best? Ved første øyekast må det være den andre, mye bedre.
Når skal man sende parametere mellom lag med normale variabeltyper (int, string, guid, double), og hva skal man sende med Model? Følgende metoder:
SelectUser(int UserId)
SelectUserByName (strengbrukernavn)
SelectUserByName(strengbrukernavn, strengpassord)
SelectUserByEmail (streng e-post)
SelectUserByEmail(streng e-post, strengpassord)
Det kan oppsummeres som:
SelectUser(userId)
SelectUser(bruker)
Her bruker vi brukermodellobjektet for å inkludere fire kombinasjonsmoduser: brukernavn, passord og e-post. UserId kan også slås sammen med user, men andre BLL i prosjektet implementerer grensesnitt med id-parametere, så dette elementet beholdes også.
userInfo blir sendt, så hvordan håndteres det, dette må være i rekkefølgen, det er en spesifikk kode å bestemme.
Her behandles det i denne rekkefølgen
Først, sjekk om du har både brukernavn og passord, så om du har både e-post og passord, så om du har brukernavn, og så om du har e-post. Behandlet sekvensielt.
På denne måten, hvis et nytt innhold legges til i fremtiden, medlemskortet (nummeret), er det ikke nødvendig å endre grensesnittet, bare legge til støtte for nummer i DAL-koden, og deretter legge til ytelse og behandling av medlemskortinnholdet i forgrunnen.
4、UserDAL.cs
offentlig IList SelectUsers(): Returnerer en liste over all brukerinformasjon
offentlig UserInfo SelectUser(int UserId): Returnerer den betrodde informasjonen til den angitte brukeren
offentlig bool InsertUser(UserInfo User): Lagt til brukerinformasjon
offentlig bool UpdateUser(UserInfo User): Oppdaterer brukerinformasjon
public void DeleteUser(int UserId): Fjerner brukerinformasjon
Det mange ikke klarer å finne ut av mest, er dataadgangslaget, hvilken del regnes som datatilgangslaget? Noen tror at databasen er datatilgangslaget, noe som ikke er klart i definisjonen, DAL er datatilgangslaget og ikke datalagringslaget, så databasen kan ikke være dette laget. SQLHelpers rolle er å redusere repeterende koding og forbedre kodingseffektiviteten, så hvis jeg er vant til å bry meg om effektivitet eller bruke en ikke-databasebasert datakilde, kan jeg forkaste SQLHelper, en del som kan kastes når som helst, hvordan kan det bli et lag i tre-lags arkitekturen.
Den kan defineres slik: koden knyttet til datakildeoperasjoner bør plasseres i dataaksesslaget, som tilhører dataaksesslaget
5、IUserDAL
Datatilgangslagets grensesnitt, dette er en annen overflødig ting, fordi Petshop bringer det og ClassFactory med seg, så noen prosjekter gjør disse to tingene uavhengig av om de trenger å støtte flere datakilder eller ikke, og noen bygger til og med ikke ClassFactory, men bare IDAL, og så "IUserDAL iUserDal = ny UserDAL(); Jeg vet ikke hva meningen er. Dette er helt klart en tiger og ikke en anti-hund.
Mange har en misforståelse her, nemlig at det finnes en slik sammenheng: BLL?àIDAL?àDAL, som tror at IDAL fungerer som en bro mellom BLL og DAL, og BLL kaller DAL gjennom IDAL. Men realiteten er at selv om du koder det slik: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Når man kjører "iUserDal.SelectUsers()", er det faktisk UserDAL-instansen som kjøres, ikke IUserDAL-instansen, så posisjonen til IDAL i det tredje laget er relatert til DAL-nivået.
Gjennom innledningen ovenfor forklares hierarkiet i tre-nivåarkitekturen i hovedsak. Faktisk har jeg en måte å vurdere om trelagsarkitekturen er standard, det vil si at fullstendig utskifting av ett av de tre lagene ikke vil påvirke de to andre lagene, og en slik struktur oppfyller i bunn og grunn trelagsstandarden (selv om det er vanskeligere ^_^ å implementere). For eksempel, hvis du endrer prosjektet fra B/S til C/S (eller omvendt), trenger ikke BLL og DAL å endres bortsett fra UI; Eller endre SQLServer til Oracle, bare bytt SQLServerDAL ut med OracleDAL, ingen andre operasjoner kreves, osv. Jeg ønsket opprinnelig å legge til litt spesifikk kode i artikkelen, men jeg føler ikke det er nødvendig, hvis du mener det er nødvendig, vil jeg legge det til.
Sammendrag: Ikke tro at et lag er unødvendig bare fordi det er ubrukelig for deg, eller at det er spesielt enkelt å implementere, eller forlat det, eller bruk det til andre formål. Så lenge lagene gjennomføres, uansett hvor mange lag det er, må hvert lag ha et klart formål og funksjonsrealisering, og ikke påvirkes av selve prosessen, noe som resulterer i at samme type fil befinner seg i forskjellige lag. Ikke la det samme laget implementere forskjellige funksjoner. |
Publisert på 07.05.2015 10:53:35
|
|
|
