BLL ir biznesa loģikas slānis
DAL ir datu piekļuves slānis
Trīspakāpju ASP.NET arhitektūra (DAL, BLL, UI)
Grafika attēlo trīsslāņu struktūru. Tīmeklis ir USL slānis
tīmeklis –> bll –> dal
| | |
| V |
+–> modelis <—+
1. Trīspakāpju arhitektūra
1. Prezentācijas slānis (USL): Tas galvenokārt atspoguļo WEB metodi, bet to var izteikt arī kā WINFORM režīmu. Ja loģiskais slānis ir diezgan stabils un labi izveidots, tas lieliski kalpos neatkarīgi no tā, kā veiktspējas slānis tiek definēts un mainīts.
2. Biznesa loģikas slānis (BLL): galvenokārt konkrētām problēmām to var saprast arī kā datu slāņa darbību un datu biznesa loģisko apstrādi. Ja datu slānis ir veidošanas bloki, tad loģiskais slānis ir veidošanas bloks.
3. Datu piekļuves slānis (DAL): Tas galvenokārt ir sākotnējo datu darbības slānis (datu bāzes vai teksta faila vai cita veida datu glabāšanas veidā), nevis oriģinālie dati, tas ir, datu darbība, nevis datu bāze, īpaši biznesa loģikas slānis vai prezentācijas slānis
Datu pakalpojumu sniegšana.
2) Īpaša atšķirība
1. Prezentācijas slānis: galvenokārt pieņem lietotāja pieprasījumu un atgriež datus, nodrošinot klientam piekļuvi lietojumprogrammai.
2. Biznesa loģikas slānis: galvenokārt atbildīgs par datu slāņa darbību, tas ir, dažu datu slāņa operāciju kombināciju.
3. Datu piekļuves slānis: Tas galvenokārt ir atkarīgs no tā, vai jūsu datu slānis satur loģisku apstrādi, patiesībā tā funkcijas galvenokārt veic dažādas darbības datu failā, un nav jāuztraucas par citām darbībām.
3. Kopsavilkums
Trīs slāņu struktūra ir stingra hierarhiska pieeja, tas ir, datu piekļuves slānim (DAL) var piekļūt tikai biznesa loģikas slānis (BLL), un biznesa loģikas slānim var piekļūt tikai prezentācijas slānis (USL). Dažas trīsslāņu struktūras pievieno arī citus slāņus, piemēram, rūpnīcu un modeli, kas faktiski ir paplašinājums un pielietojums, pamatojoties uz šiem trim slāņiem.
Vienkārša trīsslāņu programma parasti ietver vairākus DAL BLL WEB modeļa projektus, un to savstarpējās atsauces ir šādas
1) WEB atsauces BLL, Modelis
2) BLL atsauces DAL, modelis
3) DAL atsauces Modelis
4) Modelim nav citātu
Runājot par trīspakāpju arhitektūru, visi zina, ka tas ir veiktspējas slānis (UI), biznesa loģikas slānis (BLL) un datu piekļuves slānis (DAL), un ir daudz veidu, kā sadalīt katru slāni. Bet kā uzrakstīt konkrēto kodu un kurā slānī šie faili tiek ieskaitīti, ir neskaidrs. Šis ir vienkāršs piemērs, lai jūs praktizētu trīsslāņu arhitektūras projektu, šim piemēram ir tikai viena funkcija, tas ir, vienkārša lietotāju pārvaldība.
Vispirms izveidojiet tukšu risinājumu un pievienojiet šādus vienumus un failus
1. Pievienojiet ASP.NET Web Application projektu, nosauciet to par UI un izveidojiet jaunu Web Form faila User.aspx (ieskaitot User.aspx.cs)
2. Pievienojiet ClassLibrary projektu, nosauciet to par BLL un izveidojiet jaunu klases failu UserBLL.cs
3. Pievienojiet ClassLibrary projektu, nosauciet to par DAL un izveidojiet jaunu klases failu UserDAL.cs. Pievienojiet SQLHelper atsauci. (Šī ir Microsoft datu piekļuves klase, vai arī visu datu piekļuves kodu var rakstīt tieši.) Es parasti izmantoju DataAccessHelper klasi, ko es rakstu).
4. Pievienojiet ClassLibrary projektu, nosauciet to par modeli un izveidojiet jaunu klases tipa failu UserModel.cs
5. Pievienojiet ClassLibrary projektu, nosauciet to par IDAL un izveidojiet jaunu interfeisa failu IUserDAL.cs
6. Pievienojiet ClassLibrary projektu un nosauciet to par ClassFactory
Es uzskatu, ka jūs esat redzējuši, ka tas neatšķiras no Petshop piemēra, un tas ir vienkāršāk, jo es arī apgūstu trīsslāņu arhitektūru, izmantojot Petshop. Tomēr daži draugi var būt neskaidri par šo projektu līmeni un attiecībām starp tiem, šeit ir to skaidrojums pa vienam:
1. User.aspx un User.aspx.cs
Abi dokumenti (un vienumi, kuriem pieder fails, kā arī zemāk, netiks atkārtoti) ir daļa no prezentācijas slāņa. User.aspx ir vieglāk saprast, jo tā ir parādāmā lapa. User.aspx.cs daži cilvēki domā, ka to nevajadzētu skaitīt, bet iekļaut biznesa loģikas slānī. Ja jūs neveicat slāņošanu, tad nav problēmu ļaut User.aspx.cs rīkoties ar biznesa loģiku un pat darbināt datu bāzi, bet, ja jūs veicat slāņošanu, to nevajadzētu darīt. Hierarhiskā struktūrā User.aspx.cs jānodarbojas tikai ar saturu, kas saistīts ar attēlošanu, un nekas cits nebūtu jāaptver.
Piemēram, ja mēs īstenojam lietotāju parādīšanas funkciju saraksta veidā, tad informācijas iegūšanas darbu veic BLL, un pēc tam, kad lietotāja interfeiss (šajā gadījumā tas ir User.aspx.cs) izsauc BL, lai iegūtu UserInfo, tas ir saistīts ar User.aspx datu kontroli, izmantojot kodu, lai realizētu saraksta parādīšanu. Šajā procesā, User.aspx.cs tam nav nozīmes lietotāja saskarnē, tas tiek izmantots tikai datu nodošanai, un, tā kā lielākā daļa faktiskās kodēšanas tiek īstenota šādi, daži cilvēki uzskata, ka User.aspx.cs nevajadzētu uzskatīt par lietotāja interfeisu, bet gan jāapvieno BLL loģiskai apstrādei. Skatoties tālāk, tika izvirzīta jauna prasība pievienot ikonu katra lietotāja priekšā, lai spilgti attēlotu lietotāja dzimumu, un tiem, kas jaunāki par 18 gadiem, to attēloja bērna ikona. Šīs prasības realizācija ir User.aspx.cs kārta, un šajā gadījumā User.aspx.cs tai ir reāla izmantošana.
2、NewBLL.cs
Pievieno šādas metodes:
public IList GetUsers(): atgriež visas lietotāja informācijas sarakstu
public UserInfo GetUser(int UserId): atgriež informāciju par norādīto lietotāju
public bool AddUser(UserInfo User): Pievienota lietotāja informācija
public bool ChangeUser(UserInfo User): Atjaunina lietotāja informāciju
public void RemoveUser(int UserId): noņem lietotāja informāciju
Šis fails pieder biznesa loģikas slānim un ir paredzēts ar biznesa loģiku saistītu darbību apstrādei. Daudzi cilvēki var domāt, ka vienīgais šī slāņa lietojums ir datu pārsūtīšana no veiktspējas slāņa uz datu slāni. Šādu gadījumu patiešām ir daudz, bet tas var nozīmēt tikai to, ka projekts ir salīdzinoši vienkāršs, vai arī attiecības starp pašu projektu un uzņēmumu nav cieši integrētas (piemēram, pašreizējā populārā MIS), tāpēc biznesa slānim nav nekāda sakara, un tam ir tikai pārsūtīšanas loma. Bet tas nenozīmē, ka biznesa slānis ir nepieciešams, jo projekts palielinās vai ir vairāk biznesa attiecību, biznesa slānis atspoguļos tā lomu.
Visticamākā kļūda ir datu operācijas koda piešķiršana biznesa loģikas slānim un datu bāzei kā datu piekļuves slānim.
Piemēram, daži draugi uzskata, ka BLL slānis nav jēgpilns, bet viņi vienkārši augšupielādē DAL datus un pārsūta tos uz lietotāja interfeisu bez jebkādas apstrādes. Apskatiet šo piemēru
BLL slānis
SelectUser(UserInfo userInfo) iegūst lietotāja informāciju, pamatojoties uz ienākošo lietotājvārdu vai e-pasta adresi.
IsExist(UserInfo userInfo) nosaka, vai norādītais lietotājvārds vai e-pasta adrese pastāv.
Tad DAL nodrošina arī atbilstošo metodi BLL izsaukumam
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Tādā veidā BLL spēlē tikai pārraides lomu.
Bet, ja jūs to darāt:
BLL. IsExist(Userinfo lietotāja informācija)
{
UerInfo lietotājs = DAL. SelectUser(Lietotājs);
atgriešanās (userInfo.Id != nulle);
}
Tad DAL nav jāievieš IsExist () metode, un BLL ir loģiskās apstrādes kods.
3、UserModel.cs
Būtība, šī lieta, jūs domājat, ka nav viegli stratificēt. Ieskaitot mani, es to sapratu šādi: UI?àModel?àBLL?àModel?àDAL, tāpēc tiek uzskatīts, ka modelis darbojas kā tilts datu pārraidei starp slāņiem. Bet šeit mēs nedomājam par vienkāršām lietām, bet par sarežģītību.
Kas ir modelis? Tas nav nekas! Tas ir izdevīgs trīspakāpju arhitektūrā. Patiesībā tā ir visvienkāršākā lieta objektorientētā programmēšanā: klases. Tabula ir klase, ziņas ir arī klase, int, virkne, dubultā utt. ir arī klases, tā ir tikai klase.
Tādā veidā modeļa stāvoklis trīsslāņu arhitektūrā ir tāds pats kā mainīgo, piemēram, int un virknes, statuss, un tam nav cita mērķa, to izmanto tikai datu glabāšanai, bet glabā sarežģītus datus. Tāpēc, ja jūsu projekta objekti ir ļoti vienkārši, tad jūs varat tieši nodot vairākus parametrus bez modeļa, lai izveidotu trīsslāņu arhitektūru.
Tātad, kāpēc jums ir nepieciešams modelis un kādas ir tā priekšrocības? Domājot par šeit ievietotu jautājumu, nāk prātā:
Vai modelim var būt lielāka loma parametru pārejā katrā slānī?
Nododot parametrus starp slāņiem, varat rīkoties šādi:
AddUser(lietotāja_ID,lietotājvārds,lietotāja parole,...,)
Tas var būt arī šāds:
AddUser(lietotāja informācija)
Kura no šīm divām metodēm ir labāka? Īsumā tam jābūt otrajam daudz labākam.
Kad nodot parametrus starp slāņiem ar normāliem mainīgo tipiem (int, virkne, guid, dubultā) un ko nodot ar modeli? Šādas metodes:
SelectUser(int UserId)
SelectUserByName(virknes lietotājvārds)
SelectUserByName(virknes lietotājvārds,virknes parole)
SelectUserByEmail(virknes e-pasts)
SelectUserByEmail(virknes e-pasts,virknes parole)
To var apkopot kā:
SelectUser(userId)
SelectUser(lietotājs)
Šeit mēs izmantojam lietotāja modeļa objektu, lai iekļautu četrus lietotājvārda, paroles un e-pasta kombinācijas režīmus. UserId var arī apvienot ar lietotāju, bet citi BLL projektā ievieš saskarnes ar id parametriem, tāpēc arī šis vienums tiek saglabāts.
userInfo tiek nodots, tātad, kā ar to rīkoties, tam jābūt kārtībā, ir jāizlemj īpašs kods.
Šeit tas tiek apstrādāts šādā secībā
Vispirms pārbaudiet, vai jums ir gan lietotājvārds, gan parole, pēc tam pārbaudiet, vai jums ir gan e-pasts, gan parole, pēc tam pārbaudiet, vai jums ir lietotājvārds, un pēc tam pārbaudiet, vai jums ir e-pasts. Apstrādāts secīgi.
Tādā veidā, ja nākotnē tiek pievienots jauns saturs, biedra karte (numurs), nav nepieciešams mainīt saskarni, vienkārši pievienojiet atbalstu numuram DAL kodā un pēc tam pievienojiet dalības kartes satura veiktspēju un apstrādi priekšplānā.
4、UserDAL.cs
public IList SelectUsers(): atgriež sarakstu ar visu lietotāju informāciju
public UserInfo SelectUser(int UserId): atgriež norādītā lietotāja uzticamo informāciju
public bool InsertUser(UserInfo User): Pievienota lietotāja informācija
public bool UpdateUser(UserInfo User): Atjaunina lietotāja informāciju
public void DeleteUser(int UserId): noņem lietotāja informāciju
Tas, ko daudzi cilvēki nevar izdomāt visvairāk, ir datu piekļuves slānis, kura daļa tiek uzskatīta par datu piekļuves slāni? Daži cilvēki domā, ka datu bāze ir datu piekļuves slānis, kas nav skaidrs par definīciju, DAL ir datu piekļuves slānis, nevis datu glabāšanas slānis, tāpēc datu bāze nevar būt šis slānis. SQLHelper loma ir samazināt atkārtotu kodēšanu un uzlabot kodēšanas efektivitāti, tāpēc, ja esmu pieradis rūpēties par efektivitāti vai izmantot datu avotu, kas nav datu bāze, es varu atmest SQLHelper, daļu, kuru var izmest pēc vēlēšanās, kā tā var kļūt par trīsslāņu arhitektūras slāni.
To var definēt šādi: kods, kas saistīts ar datu avota operācijām, jāievieto datu piekļuves slānī, kas pieder pie datu piekļuves slāņa
5、IUserDAL
Datu piekļuves slāņa interfeiss, šī ir vēl viena liekama lieta, jo Petshop to un ClassFactory rūpnīcu sev līdzi, tāpēc daži projekti dara šīs divas lietas neatkarīgi no tā, vai tiem ir jāatbalsta vairāki datu avoti vai nē, un daži pat neveido ClassFactory, bet tikai veido IDAL, un pēc tam "IUserDAL iUserDal = jauns UserDAL(); Es nezinu, kāda ir nozīme. Tas ir pilnīgi tīģeris, nevis anti-suns.
Daudziem cilvēkiem šeit ir nepareizs priekšstats, tas ir, ka pastāv šādas attiecības: BLL?àIDAL?àDAL, domājot, ka IDAL darbojas kā tilts starp BLL un DAL, un BLL sauc DAL caur IDAL. Bet realitāte ir tāda, ka pat tad, ja jūs to kodējat šādā veidā: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Izpildot "iUserDal.SelectUsers()", faktiski tiek izpildīta UserDAL instance, nevis IUserDAL instance, tāpēc IDAL pozīcija trešajā slānī ir saistīta ar DAL līmeni.
Izmantojot iepriekš minēto ievadu, pamatā tiek izskaidrota trīspakāpju arhitektūras hierarhija. Patiesībā man ir veids, kā spriest, vai trīsslāņu arhitektūra ir standarta, tas ir, pilnīga jebkura no trim slāņiem nomaiņa neietekmēs pārējos divus slāņus, un šāda struktūra būtībā atbilst trīsslāņu standartam (lai gan to ir grūtāk ^_^ īstenot). Piemēram, ja maināt projektu no B/S uz C/S (vai otrādi), tad BLL un DAL nav jāmaina, izņemot lietotāja interfeisu; Vai arī nomainiet SQLServer uz Oracle, vienkārši nomainiet SQLServerDAL uz OracleDAL, citas darbības nav nepieciešamas utt. Es sākotnēji gribēju pievienot rakstam kādu konkrētu kodu, bet es neuzskatu, ka tas ir nepieciešams, ja jūs uzskatāt, ka tas ir nepieciešams, es to pievienošu.
Kopsavilkums: Nedomājiet, ka slānis ir nevajadzīgs tikai tāpēc, ka tas jums ir bezjēdzīgs, vai to ir īpaši vienkārši ieviest, vai atteikties no tā, vai izmantot citiem mērķiem. Kamēr slāņi tiek veikti, neatkarīgi no tā, cik slāņu ir, katram slānim ir jābūt skaidram mērķim un funkciju realizācijai, un to nedrīkst ietekmēt faktiskais process, kā rezultātā viena veida fails atrodas dažādos slāņos. Neļaujiet vienam un tam pašam slānim īstenot dažādas funkcijas. |
Publicēts 07.05.2015 10:53:35
|
|
|
