BLL on Business Logic -kerros
DAL on Data Access Layer
Kolmitasoinen arkkitehtuuri ASP.NET (DAL, BLL, UI)
Grafiikka edustaa kolmitasoista rakennetta. Verkko on USL-kerros
Web –> BLL –> dal
| | |
| V |
+–> malli <—+
1. Kolmitasoinen arkkitehtuuri
1. Esityskerros (USL): Se edustaa pääasiassa WEB-menetelmää, mutta voidaan myös ilmaista WINFORM-tilana. Jos logiikkakerros on melko kestävä ja vakiintunut, se toimii täydellisesti riippumatta siitä, miten suorituskykykerros määritellään ja muutetaan.
2. Liiketoimintalogiikkakerros (BLL): pääasiassa erityisiin ongelmiin, sitä voidaan ymmärtää myös datakerroksen toimintana ja dataliiketoiminnan loogisena käsittelynä. Jos datakerros on rakennuspalikat, niin logiikkakerros on rakennuspalikka.
3. Tietojen käyttökerros (DAL): Se on pääasiassa alkuperäisen datan toimintakerros (tietokannan, tekstitiedoston tai muun datan tallennusmuodon muodossa), eikä alkuperäinen data, eli datan toiminta, ei tietokanta, erityisesti liiketoimintalogiikkakerros tai esityskerros
Datapalveluiden tarjoaminen.
2. Erityinen ero
1. Esityskerros: hyväksyy pääasiassa käyttäjän pyynnön ja palauttaa tietoja, tarjoten asiakkaalle pääsyn sovellukseen.
2. Liiketoimintalogiikkakerros: pääasiassa vastuussa datakerroksen toiminnasta, eli joidenkin tietokerrostoimintojen yhdistämisestä.
3. Tietojen käyttökerros: Se riippuu pääasiassa siitä, sisältääkö tietokerros loogista prosessointia, itse asiassa sen toiminnot suorittavat pääasiassa erilaisia operaatioita tiedostossa, eikä tarvitse huolehtia muista operaatioista.
3. Yhteenveto
Kolmikerroksinen rakenne on tiukka hierarkkinen lähestymistapa, eli datan pääsykerrosta (DAL) voi käyttää vain liiketoimintalogiikkakerros (BLL) ja liiketoimintalogiikkakerrosta vain esityskerros (USL). Jotkut kolmikerroksiset rakenteet lisäävät myös muita kerroksia, kuten Factory ja Model, jotka ovat itse asiassa laajennus ja sovellus näiden kolmen kerroksen pohjalta.
Yksinkertainen kolmikerroksinen ohjelma sisältää yleensä useita DAL BLL WEB -mallin projekteja, ja niiden keskinäiset viittaukset ovat seuraavat
1) WEB-viittaukset BLL, malli
2) BLL-viittaukset DAL:iin, malliin
3) DAL viittaa malliin
4) Mallissa ei ole viitteitä
Kolmitasoisessa arkkitehtuurissa kaikki tietävät, että kyseessä ovat suorituskykykerros (UI), liiketoimintalogiikkakerros (BLL) ja datan käyttökerros (DAL), ja kerroksia voidaan jakaa monin tavoin. Mutta miten kirjoitetaan kyseinen koodi ja mihin kerrokseen tiedostot lasketaan, on epämääräistä. Seuraava on yksinkertainen esimerkki, joka johdattaa sinut harjoittelemaan kolmitasoista arkkitehtuuriprojektia; tässä esimerkissä on vain yksi toiminto, eli käyttäjien yksinkertainen hallinta.
Ensiksi luo tyhjä ratkaisu ja lisää seuraavat kohteet ja tiedostot
1. Lisää ASP.NET Web Application -projekti, nimeä se käyttöliittymä ja luo uusi Web Form -tiedosto User.aspx (mukaan lukien User.aspx.cs)
2. Lisää ClassLibrary-projekti, nimeä se BLL:ksi ja luo uusi Class-tiedosto UserBLL.cs
3. Lisää ClassLibrary-projekti, nimeä se DAL:ksi ja luo uusi Class-tiedosto UserDAL.cs. Lisää SQLHelper-viite. (Tämä on Microsoftin data access -luokka, tai voit kirjoittaa kaiken datan käyttökoodin suoraan.) Käytän yleensä DataAccessHelper-kurssia, jota kirjoitan).
4. Lisää ClassLibrary-projekti, nimeä se Modeliksi ja luo uusi Class-tyyppinen tiedosto UserModel.cs
5. Lisää ClassLibrary-projekti, nimeä se IDALiksi ja luo uusi Interface-tiedosto IUserDAL.cs
6. Lisää ClassLibrary-projekti ja nimeä se ClassFactoryksi
Uskon, että olet nähnyt, että tämä ei eroa Petshopin esimerkistä, ja se on yksinkertaisempaa, koska opin myös kolmikerroksisen arkkitehtuurin Petshopin kautta. Jotkut ystävät saattavat kuitenkin olla epämääräisiä näiden projektien tasosta ja niiden välisestä suhteesta, tässä on selitys niistä yksi kerrallaan:
1. User.aspx ja User.aspx.cs
Molemmat asiakirjat (ja ne kohteet, joihin tiedosto kuuluu, samoin kuin alla, eivät toisteta) ovat osa esityskerrosta. User.aspx on helpompi ymmärtää, koska kyseessä on näyttösivu. User.aspx.cs jotkut ajattelevat, ettei sitä pitäisi laskea, vaan sisällyttää liiketoimintalogiikkakerrokseen. Jos et tee kerrostamista, ei ole ongelmaa antaa User.aspx.cs hoitaa liiketoimintalogiikkaa ja jopa käyttää tietokantaa, mutta jos teet kerrostamista, tätä ei pitäisi tehdä. Hierarkkisessa rakenteessa User.aspx.cs tulisi käsitellä vain näyttöön liittyvää sisältöä, eikä muuta tulisi käsitellä.
Esimerkiksi, jos toteutamme käyttäjien näyttämisen listan muodossa, tiedon erottaminen tehdään BLL:llä, ja kun käyttöliittymä (tässä tapauksessa se on User.aspx.cs) kutsuu BLL:ää saadakseen UserInfon, se sidotaan User.aspx:n datan hallintaan koodin kautta listan näyttämisen toteuttamiseksi. Tässä prosessissa User.aspx.cs sillä ei ole roolia käyttöliittymässä, sitä käytetään vain datan siirtoon, ja koska suurin osa varsinaisesta koodauksesta toteutetaan näin, jotkut ajattelevat, että User.aspx.cs ei pitäisi laskea käyttöliittymäksi, vaan yhdistää BLL:ään loogista käsittelyä varten. Tarkemmin katsottuna asetettiin uusi vaatimus lisätä kuvake jokaisen käyttäjän eteen kuvakkeeksi, joka edustaa käyttäjän sukupuolta elävästi, ja alle 18-vuotiaille se esitettiin lapsikuvakkeella. Tämän vaatimuksen toteutuminen on User.aspx.cs vuoro, ja tässä tapauksessa User.aspx.cs sillä on todellinen käyttötarkoitus.
2、NewBLL.cs
Lisää seuraavat menetelmät:
julkinen IList GetUsers(): Palauttaa listan kaikista käyttäjätiedoista
public UserInfo GetUser(int UserId): Palauttaa määritellyn käyttäjän tiedot
public bool AddUser(UserInfo User): Lisätty käyttäjätiedot
public bool ChangeUser(UserInfo User): Päivittää käyttäjätiedot
public void RemoveUser(int UserId): Poistaa käyttäjätiedot
Tämä tiedosto kuuluu liiketoimintalogiikkakerrokseen ja on omistettu liiketoimintalogiikkaan liittyvien operaatioiden käsittelyyn. Monet saattavat ajatella, että tämän kerroksen ainoa käyttötarkoitus on siirtää data suorituskykykerroksesta datakerrokseen. Tällaisia tapauksia on kyllä monia, mutta tämä voi tarkoittaa vain sitä, että projekti on suhteellisen yksinkertainen tai että projektin ja liiketoiminnan välinen suhde ei ole tiiviisti integroitu (kuten nykyinen suosittu MIS), joten liiketoimintakerroksella ei ole mitään tekemistä ja se toimii vain eteenpäin suuntautuvana roolina. Tämä ei kuitenkaan tarkoita, että liiketoimintakerros olisi korvaamaton, sillä kun projekti kasvaa tai liiketoimintasuhteita on enemmän, liiketoimintakerros heijastaa sen roolia.
Todennäköisin virhe on määrittää datan operaatiokoodi liiketoimintalogiikkakerrokseen ja tietokanta datan käyttökerrokseksi.
Esimerkiksi jotkut ystävät kokevat, ettei BLL-kerros ole merkityksellinen, mutta he vain lataavat DAL-datan ja lähettävät ne käyttöliittymään ilman mitään käsittelyä. Katso tätä esimerkkiä
BLL-kerros
SelectUser(UserInfo userInfo) saa käyttäjätiedot käyttäjätunnuksen tai sähköpostin perusteella.
IsExist(UserInfo userInfo) määrittää, onko määritelty käyttäjätunnus tai sähköposti olemassa.
Tällöin DAL tarjoaa vastaavan menetelmän BLL-kutsulle
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Näin BLL toimii vain siirtona.
Mutta jos teet niin:
BLL. IsExist(Käyttäjätiedot)
{
UerInfo-käyttäjä = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Silloin DAL:n ei tarvitse toteuttaa IsExist()-metodia, ja BLL:ssä on loogista prosessointikoodia.
3、UserModel.cs
Entiteetin, tämän olennon, saatat ajatella, ettei ole helppoa stratifioida. Minä mukaan lukien ymmärsin asian näin: UI?àModel?àBLL?àModel?àDAL, joten uskotaan, että malli toimii siltana kerrosten väliselle tiedonsiirrolle. Mutta tässä emme ajattele asioita yksinkertaisina, vaan monimutkaisuutena.
Mikä on malli? Ei se mitään! Se on korvaamaton kolmitasoisessa arkkitehtuurissa. Se on itse asiassa olio-ohjelmoinnin perusasia: luokat. Taulukko on luokka, uutinen on myös kurssi, int, string, doublie jne. ovat myös kursseja, se on vain kurssi.
Näin mallin sijainti kolmikerroksisessa arkkitehtuurissa on sama kuin muuttujien, kuten int:n ja merkkijonon, tila, eikä sillä ole muuta tarkoitusta, sitä käytetään vain datan tallennukseen, mutta se tallentaa monimutkaista dataa. Siksi, jos projektisi objektit ovat hyvin yksinkertaisia, voit suoraan välittää useita parametreja ilman mallia luodaksesi kolmikerroksisen arkkitehtuurin.
Miksi siis tarvitset mallin, ja mitkä ovat sen hyödyt? Seuraava on se, mikä tulee mieleen, kun miettii tähän lisättyä kysymystä:
Voiko mallilla olla suurempi rooli parametrien siirtymisessä jokaisessa kerroksessa?
Kun siirrät parametreja kerrosten välillä, voit tehdä seuraavaa:
AddUser(userId,userName,userPassword,...,)
Se voi olla myös näin:
AddUser(userInfo)
Kumpi näistä kahdesta menetelmästä on parempi? Ensisilmäyksellä se on varmasti toinen paljon parempi.
Milloin parametrit välitetään kerrosten välillä, joissa on normaalit muuttujatyypit (int, string, guid, double), ja mitä välittää mallilla? Seuraavat menetelmät:
SelectUser(int UserId)
SelectUserByName(merkkijonon käyttäjätunnus)
SelectUserByName(merkkijono, käyttäjätunnus, merkkijonon salasana)
SelectUserByEmail (merkkijono-sähköposti)
SelectUserByEmail (merkkijono sähköposti, merkkimerkkimerkki salasana)
Se voidaan tiivistää seuraavasti:
SelectUser(userId)
SelectUser(käyttäjä)
Tässä käytämme käyttäjämallin objektia sisältämään neljä yhdistelmätilaa: käyttäjätunnus, salasana ja sähköposti. UserId voidaan myös yhdistää useriksi, mutta muut projektin BLL:t toteuttavat rajapinnat id-parametreilla, joten tämäkin kohde säilyy.
userInfo on ohi, joten miten käsitellä sitä, tämän täytyy olla järjestyksessä, ja on olemassa tietty koodi, josta voi päätellä.
Tässä se käsitellään tässä järjestyksessä
Ensin katso, onko sinulla sekä käyttäjätunnus että salasana, sitten onko sinulla sekä sähköposti että salasana, sitten käyttäjätunnus ja lopuksi sähköposti. Käsitelty peräkkäin.
Näin ollen, jos tulevaisuudessa lisätään uutta sisältöä, jäsenkortti (numero), ei tarvitse muuttaa käyttöliittymää, vaan lisätään vain tuki numerolle DAL-koodiin ja lisätään jäsenkortin sisällön suorituskyky ja käsittely etualalle.
4、UserDAL.cs
julkinen IList SelectUsers(): Palauttaa listan kaikista käyttäjätiedoista
public UserInfo SelectUser(int UserId): Palauttaa määritellyn käyttäjän luotetut tiedot
public bool InsertUser(UserInfo User): Lisätty käyttäjätiedot
public bool UpdateUser(UserInfo User): Päivittää käyttäjätiedot
public void DeleteUser(int UserId): Poistaa käyttäjätiedot
Monet eivät ymmärrä eniten datan pääsykerrosta, mikä osa on datan pääsykerros? Jotkut ajattelevat, että tietokanta on datan käyttökerros, mikä ei ole selkeä määritelmässä, DAL on tiedonhakukerros eikä tallennuskerros, joten tietokanta ei voi olla tämä kerros. SQLHelperin rooli on vähentää toistuvaa koodausta ja parantaa koodauksen tehokkuutta, joten jos olen tottunut välittämään tehokkuudesta tai käyttämään ei-tietokantatietolähdettä, voin hylätä SQLHelperin, osan, jonka voi hylätä halutessani, miten siitä voi tulla kolmikerroksisen arkkitehtuurin kerros.
Se voidaan määritellä seuraavasti: tietolähdetoimintoihin liittyvä koodi tulee sijoittaa datan käyttökerrokseen, joka kuuluu datan käyttökerrokseen
5、IUserDAL
Datan käyttökerrosrajapinta, tämä on toinen välttämätön asia, koska Petshop tuo sen ja ClassFactory mukanaan, joten jotkut projektit tekevät nämä kaksi asiaa riippumatta siitä, pitääkö niiden tukea useita tietolähteitä vai eivät, ja jotkut eivät rakenna ClassFactorya vaan rakentavat vain IDAL:n, ja sitten "IUserDAL iUserDal = uusi UserDAL(); En tiedä, mitä se tarkoittaa. Tämä on täysin tiikeri eikä koiravastainen.
Monilla ihmisillä on tässä väärinkäsitys, eli että tällainen suhde on olemassa: BLL?àIDAL?àDAL, joka ajattelee IDALin toimivan sillanrakentajana BLL:n ja DAL:n välillä, ja BLL kutsuu DAL:ia IDALin kautta. Mutta todellisuus on, että vaikka koodaisit sen näin: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Kun suoritetaan "iUserDal.SelectUsers()", suoritetaan itse asiassa UserDAL-instanssi, ei IUserDAL-instanssi, joten IDAL:n sijainti kolmannessa kerroksessa liittyy DAL-tasoon.
Yllä olevan johdannon kautta selitetään kolmitasoisen arkkitehtuurin hierarkia käytännössä. Itse asiassa minulla on tapa arvioida, onko kolmikerroksinen arkkitehtuuri standardi, eli minkään kolmen kerroksen täydellinen korvaaminen ei vaikuta muihin kahteen kerrokseen, ja tällainen rakenne täyttää käytännössä kolmikerroksisen standardin (vaikka sen toteuttaminen onkin vaikeampaa ^_^). Esimerkiksi, jos vaihdat projektin B/S:stä C/S:ään (tai päinvastoin), BLL:ää ja DAL:ia ei tarvitse muuttaa paitsi käyttöliittymän osalta; Tai vaihda SQLServer Oracleksi, korvaa SQLServerDAL OracleDALiksi, muita operaatioita ei tarvita jne. Alun perin halusin lisätä artikkeliin jonkin tietyn koodin, mutta en koe sen tarpeelliseksi – jos sinä koet sen tarpeelliseksi, lisään sen.
Yhteenveto: Älä ajattele, että kerros on tarpeeton vain siksi, että se on sinulle hyödytön, tai sen toteuttaminen on erityisen helppoa, hylkää se tai käytä sitä muihin tarkoituksiin. Niin kauan kuin kerrokset toteutetaan, riippumatta kerrosten määrästä, jokaisella kerroksella täytyy olla selkeä tarkoitus ja toiminnallisuuden toteutus, eikä sitä saa ohjata itse prosessi, jolloin samantyyppinen tiedosto sijaitsee eri kerroksissa. Älä anna saman kerroksen toteuttaa eri toimintoja. |
Julkaistu 7.5.2015 10.53.35
|
|
|
