BLL yra verslo logikos sluoksnis
DAL yra duomenų prieigos sluoksnis
Trijų pakopų ASP.NET architektūra (DAL, BLL, UI)
Grafika atspindi trijų sluoksnių struktūrą. Žiniatinklis yra USL sluoksnis
web –> bll –> dal
| | |
| V |
+–> modelis <—+
1. Trijų pakopų architektūra
1. Pristatymo sluoksnis (USL): Jis daugiausia reiškia WEB metodą, bet taip pat gali būti išreikštas kaip WINFORM režimas. Jei loginis sluoksnis yra gana tvirtas ir nusistovėjęs, jis puikiai tarnaus, nesvarbu, kaip bus apibrėžtas ir pakeistas našumo sluoksnis.
2. Verslo loginis sluoksnis (BLL): daugiausia konkrečioms problemoms spręsti jis taip pat gali būti suprantamas kaip duomenų sluoksnio veikimas ir loginis duomenų verslo apdorojimas. Jei duomenų sluoksnis yra kūrimo blokai, tada loginis sluoksnis yra kūrimo blokas.
3. Duomenų prieigos sluoksnis (DAL): Tai daugiausia yra pradinių duomenų operacijų sluoksnis (duomenų bazės ar tekstinio failo ar kitos duomenų saugojimo formos pavidalu), o ne pradiniai duomenys, tai yra duomenų, o ne duomenų bazės, konkrečiai verslo logikos ar pateikimo sluoksnio veikimas
Duomenų paslaugų teikimas.
2. Konkretus atskyrimas
1. Pristatymo sluoksnis: daugiausia priima vartotojo užklausą ir grąžina duomenis, suteikdamas klientui prieigą prie programos.
2. Verslo logikos sluoksnis: daugiausia atsakingas už duomenų sluoksnio veikimą, tai yra kai kurių duomenų sluoksnio operacijų derinį.
3. Duomenų prieigos sluoksnis: Tai daugiausia priklauso nuo to, ar jūsų duomenų sluoksnyje yra loginis apdorojimas, iš tikrųjų jo funkcijos daugiausia atlieka įvairias duomenų failo operacijas ir nereikia jaudintis dėl kitų operacijų.
3. Santrauka
Trijų sluoksnių struktūra yra griežtas hierarchinis požiūris, tai yra, duomenų prieigos sluoksnį (DAL) gali pasiekti tik verslo logikos sluoksnis (BLL), o verslo logikos sluoksnį - tik pristatymo sluoksnis (USL). Kai kurios trijų sluoksnių struktūros taip pat prideda kitus sluoksnius, tokius kaip gamykla ir modelis, kurie iš tikrųjų yra šių trijų sluoksnių išplėtimas ir pritaikymas.
Paprasta trijų sluoksnių programa paprastai apima kelis DAL BLL WEB modelio projektus, o jų tarpusavio nuorodos yra šios
1) WEB nuorodos BLL, Modelis
2) BLL nuorodos DAL, modelis
3) DAL nuorodos Modelis
4) Modelis neturi citatų
Kalbant apie trijų pakopų architektūrą, visi žino, kad tai yra našumo sluoksnis (UI), verslo logikos sluoksnis (BLL) ir duomenų prieigos sluoksnis (DAL), ir yra daug būdų, kaip suskirstyti kiekvieną sluoksnį. Tačiau neaišku, kaip parašyti konkretų kodą ir kuriame sluoksnyje tie failai skaičiuojami. Toliau pateikiamas paprastas pavyzdys, padėsiantis praktikuoti trijų sluoksnių architektūros projektą, šis pavyzdys turi tik vieną funkciją, tai yra paprastą vartotojų valdymą.
Pirmiausia sukurkite tuščią sprendimą ir įtraukite šiuos elementus bei failus
1. Pridėkite ASP.NET žiniatinklio programos projektą, pavadinkite jį vartotojo sąsaja ir sukurkite naują žiniatinklio formos failo User.aspx (įskaitant User.aspx.cs)
2. Pridėkite "ClassLibrary" projektą, pavadinkite jį BLL ir sukurkite naują klasės failo UserBLL.cs
3. Pridėkite "ClassLibrary" projektą, pavadinkite jį DAL ir sukurkite naują "Class" failo UserDAL.cs. Įtraukite SQLHelper nuorodą. (Tai yra "Microsoft" duomenų prieigos klasė arba galite parašyti visą duomenų prieigos kodą tiesiogiai.) Aš paprastai naudoju DataAccessHelper klasę, kad aš rašau).
4. Pridėkite "ClassLibrary" projektą, pavadinkite jį "Modelis" ir sukurkite naują "Class" tipo failo UserModel.cs
5. Pridėkite "ClassLibrary" projektą, pavadinkite jį IDAL ir sukurkite naują sąsajos failą IUserDAL.cs
6. Pridėkite "ClassLibrary" projektą ir pavadinkite jį "ClassFactory".
Manau, kad matėte, kad tai niekuo nesiskiria nuo "Petshop" pavyzdžio, ir tai yra paprasčiau, nes aš taip pat mokausi trijų sluoksnių architektūros per "Petshop". Tačiau kai kurie draugai gali būti neaiškūs dėl šių projektų lygio ir jų santykių, čia yra jų paaiškinimas po vieną:
1. User.aspx ir User.aspx.cs
Abu dokumentai (ir elementai, kuriems priklauso failas, taip pat žemiau, nebus kartojami) yra pristatymo sluoksnio dalis. User.aspx lengviau suprasti, nes tai yra rodomas puslapis. User.aspx.cs kai kurie žmonės mano, kad jis neturėtų būti skaičiuojamas, bet turėtų būti įtrauktas į verslo logikos sluoksnį. Jei nedarote sluoksniavimo, tada nėra problemų leisti User.aspx.cs tvarkyti verslo logiką ir net valdyti duomenų bazę, bet jei darote sluoksniavimą, tai neturėtų būti daroma. Hierarchinėje struktūroje User.aspx.cs turėtų būti susiję tik su turiniu, susijusiu su rodymu, ir nieko daugiau neturėtų būti aprėpiama.
Pavyzdžiui, jei įgyvendiname vartotojų rodymo sąrašo pavidalu funkciją, tada informacijos išgavimo darbą atlieka BLL, o po to, kai vartotojo sąsaja (šiuo atveju User.aspx.cs) iškviečia BL, kad gautų "UserInfo", ji yra susieta su User.aspx duomenų valdymu per kodą, kad būtų galima realizuoti sąrašo rodymą. Šiame procese User.aspx.cs jis nevaidina vaidmens vartotojo sąsajoje, jis naudojamas tik duomenims perduoti, o kadangi didžioji dalis faktinio kodavimo yra įgyvendinta taip, kai kurie žmonės mano, kad User.aspx.cs neturėtų būti skaičiuojamas kaip vartotojo sąsaja, o turėtų būti sujungtas į BLL loginiam apdorojimui. Žvelgiant toliau, buvo iškeltas naujas reikalavimas prieš kiekvieną vartotoją pridėti piktogramą, kuri ryškiai atspindėtų vartotojo lytį, o jaunesniems nei 18 metų asmenims ji buvo pavaizduota vaiko piktograma. Šio reikalavimo įgyvendinimas yra User.aspx.cs eilė, o šiuo atveju User.aspx.cs jis turi realią naudą.
2 、 NewBLL.cs
Įterpiami šie metodai:
public IList GetUsers(): pateikia visos vartotojo informacijos sąrašą
public UserInfo GetUser(int UserId): pateikia nurodyto vartotojo duomenis
public bool AddUser(UserInfo User): Pridėta vartotojo informacija
public bool ChangeUser(UserInfo User): Atnaujina vartotojo informaciją
public void RemoveUser(int UserId): pašalina vartotojo informaciją
Šis failas priklauso verslo logikos sluoksniui ir yra skirtas su verslo logika susijusioms operacijoms tvarkyti. Daugelis žmonių gali manyti, kad vienintelis šio sluoksnio naudojimas yra duomenų persiuntimas iš našumo sluoksnio į duomenų sluoksnį. Tokių atvejų iš tiesų yra daug, tačiau tai gali reikšti tik tai, kad projektas yra gana paprastas arba paties projekto ir verslo santykiai nėra glaudžiai integruoti (pvz., dabartinis populiarus MIS), todėl verslo sluoksnis neturi nieko bendra ir atlieka tik persiuntimo vaidmenį. Bet tai nereiškia, kad verslo sluoksnis yra nereikalingas, nes projektas didėja ar yra daugiau verslo santykių, verslo sluoksnis atspindės jo vaidmenį.
Labiausiai tikėtina klaida yra priskirti duomenų operacijos kodą verslo logikos sluoksniui ir duomenų bazei kaip duomenų prieigos sluoksniui.
Pavyzdžiui, kai kurie draugai mano, kad BLL sluoksnis nėra prasmingas, tačiau jie tiesiog įkelia DAL duomenis ir perduoda juos į vartotojo sąsają be jokio apdorojimo. Pažvelkite į šį pavyzdį
BLL sluoksnis
SelectUser(UserInfo userInfo) gauna vartotojo informaciją pagal gaunamą vartotojo vardą arba el. pašto adresą.
IsExist(UserInfo userInfo) nustato, ar nurodytas vartotojo vardas arba el. pašto adresas egzistuoja.
Tada DAL taip pat pateikia atitinkamą BLL skambučio metodą
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Tokiu būdu BLL atlieka tik perdavimo vaidmenį.
Bet jei tai padarysite:
BLL. IsExist(Vartotojo informacijos vartotojo informacija)
{
UerInfo vartotojas = DAL. PasirinkiteVartotojas(Vartotojas);
return (userInfo.Id != null);
}
Tada DAL nereikia įgyvendinti IsExist() metodo, o BLL yra loginio apdorojimo kodas.
3、UserModel.cs
Esybę, šį dalyką, galite manyti, kad nėra lengva stratifikuoti. Įskaitant mane, supratau taip: UI?àModel?àBLL?àModel?àDAL, todėl manoma, kad modelis veikia kaip tiltas duomenų perdavimui tarp sluoksnių. Bet čia mes galvojame ne apie paprastus dalykus, o apie sudėtingumą.
Kas yra modelis? Tai nieko! Tai nereikalinga trijų pakopų architektūroje. Iš tikrųjų tai yra pagrindinis objektinio programavimo dalykas: klasės. Lentelė yra klasė, naujienos taip pat yra klasė, int, styga, dvigubas ir t.t. taip pat yra klasės, tai tik klasė.
Tokiu būdu modelio padėtis trijų sluoksnių architektūroje yra tokia pati kaip kintamųjų, tokių kaip int ir string, būsena, ir jis neturi jokio kito tikslo, jis naudojamas tik duomenims saugoti, tačiau saugo sudėtingus duomenis. Todėl, jei jūsų projekto objektai yra labai paprasti, galite tiesiogiai perduoti kelis parametrus be modelio, kad sukurtumėte trijų sluoksnių architektūrą.
Taigi kodėl jums reikia modelio ir kokia jo nauda? Štai kas ateina į galvą galvojant apie čia įterptą klausimą:
Ar modelis gali vaidinti didesnį vaidmenį perduodant parametrus kiekviename sluoksnyje?
Perduodant parametrus tarp sluoksnių, galite atlikti šiuos veiksmus:
AddUser(userId,userName,userPassword,...,)
Tai taip pat gali būti taip:
AddUser(userInfo)
Kuris iš šių dviejų metodų yra geresnis? Iš pirmo žvilgsnio, tai turi būti antrasis daug geresnis.
Kada perduoti parametrus tarp sluoksnių su įprastais kintamųjų tipais (int, string, guid, double) ir ką perduoti naudojant modelį? Šie metodai:
SelectUser(int UserId)
SelectUserByName(eilutės vartotojo vardas)
SelectUserByName(eilutės vartotojo vardas,eilutės slaptažodis)
SelectUserByEmail(eilutės el. paštas)
SelectUserByEmail(eilutės el. paštas, eilutės slaptažodis)
Tai galima apibendrinti taip:
SelectUser(userId)
SelectUser(vartotojas)
Čia naudojame vartotojo modelio objektą, kad įtrauktume keturis vartotojo vardo, slaptažodžio ir el. pašto derinius. UserId taip pat gali būti sujungtas į vartotoją, tačiau kiti projekto BLL įgyvendina sąsajas su id parametrais, todėl šis elementas taip pat išlieka.
userInfo yra perduotas, taigi, kaip su juo elgtis, tai turi būti tvarkos tvarka, yra konkretus kodas, kurį reikia nuspręsti.
Čia jis apdorojamas tokia tvarka
Pirmiausia pažiūrėkite, ar turite vartotojo vardą ir slaptažodį, tada pažiūrėkite, ar turite ir el. pašto adresą, ir slaptažodį, tada pažiūrėkite, ar turite vartotojo vardą, tada pažiūrėkite, ar turite el. paštą. Apdorojama nuosekliai.
Tokiu būdu, jei ateityje bus pridėtas naujas turinys, narystės kortelė (numeris), nereikia keisti sąsajos, tiesiog pridėkite numerio palaikymą DAL kode, o tada pridėkite narystės kortelės turinio našumą ir apdorojimą pirmame plane.
4、UserDAL.cs
public IList SelectUsers(): pateikia visos vartotojo informacijos sąrašą
public UserInfo SelectUser(int UserId): pateikia patikimą nurodyto vartotojo informaciją
public bool InsertUser(UserInfo User): Pridėta vartotojo informacija
public bool UpdateUser(UserInfo User): Atnaujina vartotojo informaciją
public void DeleteUser(int UserId): pašalina vartotojo informaciją
Ko daugelis žmonių negali suprasti labiausiai, yra duomenų prieigos sluoksnis, kuris yra laikomas duomenų prieigos sluoksniu? Kai kurie žmonės mano, kad duomenų bazė yra duomenų prieigos sluoksnis, o tai nėra aišku dėl apibrėžimo, DAL yra duomenų prieigos sluoksnis, o ne duomenų saugojimo sluoksnis, todėl duomenų bazė negali būti šis sluoksnis. SQLHelper vaidmuo yra sumažinti pasikartojantį kodavimą ir pagerinti kodavimo efektyvumą, todėl, jei esu įpratęs rūpintis efektyvumu ar naudoti ne duomenų bazės duomenų šaltinį, galiu atsisakyti SQLHelper, dalies, kurią galima atsisakyti savo nuožiūra, kaip ji gali tapti trijų sluoksnių architektūros sluoksniu.
Jį galima apibrėžti taip: kodas, susijęs su duomenų šaltinio operacijomis, turėtų būti dedamas į duomenų prieigos sluoksnį, kuris priklauso duomenų prieigos sluoksniui
5 、 IUserDAL
Duomenų prieigos sluoksnio sąsaja, tai dar vienas nereikalingas dalykas, nes Petshop atneša jį ir ClassFactory gamyklą su juo, todėl kai kurie projektai daro šiuos du dalykus, nepriklausomai nuo to, ar jiems reikia palaikyti kelis duomenų šaltinius, ar ne, o kai kurie net nekuria ClassFactory, o tik kuria IDAL, ir tada "IUserDAL iUserDal = naujas UserDAL(); Nežinau, kokia prasmė. Tai visiškai tigras, o ne anti-šuo.
Daugelis žmonių čia turi klaidingą nuomonę, tai yra, kad yra toks ryšys: BLL?àIDAL?àDAL, manydami, kad IDAL veikia kaip tiltas tarp BLL ir DAL, o BLL vadina DAL per IDAL. Tačiau realybė yra tokia, kad net jei koduosite taip: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Vykdant "iUserDal.SelectUsers()", iš tikrųjų vykdomas UserDAL egzempliorius, o ne IUserDAL egzempliorius, todėl IDAL padėtis trečiajame sluoksnyje yra susijusi su DAL lygiu.
Aukščiau pateiktame įvade iš esmės paaiškinama trijų pakopų architektūros hierarchija. Tiesą sakant, aš turiu būdą spręsti, ar trijų sluoksnių architektūra yra standartinė, tai yra, visiškai pakeitus bet kurį iš trijų sluoksnių, neturės įtakos kitiems dviem sluoksniams, o tokia struktūra iš esmės atitinka trijų sluoksnių standartą (nors ją ^_^ sunkiau įgyvendinti). Pavyzdžiui, jei pakeičiate projektą iš B/S į C/S (arba atvirkščiai), BLL ir DAL nereikia keisti, išskyrus vartotojo sąsają; Arba pakeiskite SQLServer į Oracle, tiesiog pakeiskite SQLServerDAL į OracleDAL, jokių kitų operacijų nereikia ir pan. Iš pradžių norėjau pridėti kokį nors konkretų kodą prie straipsnio, bet nemanau, kad tai reikalinga, jei manote, kad tai būtina, pridėsiu.
Santrauka: Nemanykite, kad sluoksnis yra nereikalingas tik todėl, kad jis jums nenaudingas, arba jį ypač paprasta įgyvendinti, atsisakyti ar naudoti kitiems tikslams. Kol sluoksniai yra atliekami, nesvarbu, kiek sluoksnių yra, kiekvienas sluoksnis turi turėti aiškų tikslą ir funkcijos įgyvendinimą, ir neturėtų būti paveiktas faktinio proceso, todėl to paties tipo failas yra skirtinguose sluoksniuose. Neleiskite, kad tas pats sluoksnis įgyvendintų skirtingas funkcijas. |
Paskelbta 2015-05-07 10:53:35
|
|
|
