A BLL az üzleti logika réteg
A DAL az adathozzáférési réteg
Háromszintes építészet ASP.NET (DAL, BLL, UI)
A grafikák háromrétegű szerkezetet képviselnek. A web az USL réteg
Web –> bll –> dal
| | |
| V |
+–> modell <—+
1. Háromszintű építészet
1. Prezentációs réteg (USL): Főként a WEB módszert képviseli, de WINFORM módként is kifejezhető. Ha a logikai réteg elég robusztus és jól bevezetett, akkor tökéletesen szolgál, függetlenül attól, hogyan definiálják és változtatják meg a teljesítményréteget.
2. Üzleti logikai réteg (BLL): főként konkrét problémák esetén, értelmezhető az adatréteg működésének és az adatüzlet logikai feldolgozásának is. Ha az adatréteg az építőkövek, akkor a logikai réteg az építőblokk.
3. Adathozzáférési réteg (DAL): Ez elsősorban az eredeti adat működési rétege (adatbázis, szövegfájl vagy más adattárolási formában), nem pedig az eredeti adat, vagyis az adatok működése, nem az adatbázis, különösen az üzleti logikai vagy prezentációs réteg
Adatszolgáltatások nyújtása.
2. Konkrét megkülönböztetés
1. Prezentációs réteg: főként elfogadja a felhasználó kérését, és adatokat küld vissza, így az ügyfél hozzáfér az alkalmazáshoz.
2. Üzleti logikai réteg: elsősorban az adatréteg működéséért, vagyis néhány adatréteg műveletének kombinációjáért felelős.
3. Adathozzáférési réteg: Főként attól függ, hogy az adatréteg tartalmaz-e logikus feldolgozást, valójában a funkciói főként különféle műveleteket végeznek az adatfájlon, és nem kell más műveletek miatt aggódniuk.
3. Összefoglaló
A háromrétegű struktúra szigorú hierarchikus megközelítés, vagyis az adathozzáférési réteg (DAL) csak az üzleti logikai réteg (BLL) által érhető el, az üzleti logikai réteg pedig csak a prezentációs réteg (USL) által érhető el. Néhány háromrétegű struktúra más rétegeket is hozzáad, például a Factory és a Model, amelyek valójában kiterjesztést és alkalmazást jelentenek ezen három réteg alapján.
Egy egyszerű háromrétegű program általában több DAL BLL Web Model projektet tartalmaz, és ezek kölcsönös hivatkozásai a következők
1) WEB hivatkozások BLL, Modell
2) BLL utalások DAL-ra, modellre
3) DAL hivatkozások Modell
4) A modell nem tartalmaz hivatkozásokat
A háromszintű architektúrát mindenki tudja, hogy ez a teljesítményréteg (UI), az üzleti logikai réteg (BLL) és az adathozzáférési réteg (DAL), és sokféleképpen lehet minden réteget szétválasztani. De az, hogyan kell megírni a konkrét kódot, és melyik rétegben számolják ezeket a fájlokat, az homályos. Az alábbiakban egy egyszerű példa szolgál egy háromrétegű architektúraprojekt gyakorlásához, ennek csak egy funkciója van, vagyis a felhasználók egyszerű kezelése.
Először készíts egy üres megoldást, és add hozzá a következő elemeket és fájlokat
1. Adj hozzá egy ASP.NET Webalkalmazás-projektet, nevezd el UI-t, és hozz létre egy új WebForm fájlt User.aspx (beleértve a User.aspx.cs-t is)
2. Adj hozzá egy ClassLibrary projektet, nevezd el BLL-t, és hozz létre egy új Class fájlt UserBLL.cs
3. Adj hozzá egy ClassLibrary projektet, nevezd el DAL-nak, és hozz létre egy új Class fájlt UserDAL.cs. Adj hozzá egy SQLHelper hivatkozást. (Ez a Microsoft adathozzáférési osztálya, vagy az összes adathozzáférési kódot közvetlenül írhatod.) Általában a DataAccessHelper osztályt használom, amit írok).
4. Adj hozzá egy ClassLibrary projektet, nevezd el Modellnek, és hozz létre egy új Class típusú fájlt UserModel.cs
5. Adj hozzá egy ClassLibrary projektet, nevezd el IDAL-nak, és hozz létre egy új Interface fájlt IUserDAL.cs
6. Adj hozzá egy ClassLibrary projektet, és nevezd el ClassFactory-nek
Úgy gondolom, láttad, hogy ez nem különbözik a Petshop példájától, és egyszerűbb, mert én is a háromrétegű architektúrát a Petshopon keresztül tanulom. Azonban néhány barát talán homályosan fogalmazhat ezeknek a projekteknek a szintjét és a köztük lévő kapcsolatot, íme egy magyarázat róluk egyenként:
1. User.aspx és User.aspx.cs
Mindkét dokumentum (és a fájlhoz tartozó elemek, valamint az alulbók sem ismétlődnek meg) a prezentációs réteg részei. User.aspx könnyebb megérteni, mert egy megjelenítő oldalról van szó. User.aspx.cs egyesek úgy gondolják, hogy nem kellene számolni, hanem be kellene vonni az üzleti logika rétegébe. Ha nem használsz rétegzést, akkor nincs gond azzal, hogy User.aspx.cs kezeld az üzleti logikát és akár az adatbázist is, de ha rétegezed, ezt nem szabad megtenni. Hierarchikus struktúrában User.aspx.cs csak a megjelenítéshez kapcsolódó tartalommal foglalkozhat, és semmi mást nem szabad lefedni.
Például, ha a felhasználók megjelenítésének funkcióját lista formájában valósítjuk meg, akkor az információ kinyerésének munkáját BLL végzi, és miután a UI (ebben az esetben User.aspx.cs) BLL-t hívja a UserInfo megszerzéséhez, a User.aspx kódon keresztül történő adatvezérléséhez kötött, hogy a lista megjelenítését megvalósítsa. Ebben a folyamatban User.aspx.cs nem játszik szerepet a felhasználói felületen, csak adatátvitelre használják, és mivel a kódolás nagy része így van megvalósítva, egyesek úgy gondolják, hogy User.aspx.cs nem szabad UI-nak számítani, hanem logikai feldolgozáshoz a BLL-be kell integrálni. Tovább nézve új követelményt fogalmaztak meg, hogy minden felhasználó előtt egy ikon legyen, hogy élénken ábralja a nemet, és a 18 év alattiak esetében pedig egy gyermek ikonnal jelképezték. Ennek a követelménynek a megvalósítása a User.aspx.cs fordulat, és ebben az esetben User.aspx.cs valódi hasznára van szüksége.
2、NewBLL.cs
Add hozzá a következő módszereket:
public IList GetUsers(): Visszaadja az összes felhasználói információ listáját
public UserInfo GetUser(int UserId): Visszaadja a megadott felhasználó adatait
public bool AddUser(UserInfo User): Felhasználói adatok hozzáadva
public bool ChangeUser(UserInfo User): Frissíti a felhasználói adatokat
public void RemoveUser(int UserId): Eltávolítja a felhasználói adatokat
Ez a fájl az üzleti logika rétegéhez tartozik, és az üzleti logikával kapcsolatos műveletek kezelésére szolgál. Sokan azt gondolhatják, hogy ennek a rétegnek az egyetlen felhasználása az, hogy az adatokat a teljesítményrétegről az adatrétegre továbbítsuk. Valóban sok ilyen eset van, de ez csak azt jelentheti, hogy a projekt viszonylag egyszerű, vagy a projekt és az üzlet közötti kapcsolat nem szorosan integrált (mint például a jelenlegi népszerű MIS), így az üzleti rétegnek nincs szerepe, csak továbbító szerepet tölt be. Ez azonban nem jelenti azt, hogy az üzleti réteg felejthetetlen lenne, ahogy a projekt növekszik, vagy több üzleti kapcsolat alakul ki, az üzleti réteg tükrözi a szerepét.
A legvalószínűbb hiba az, ha az adatműveleti kódot az üzleti logikai réteghez rendeljük, az adatbázist pedig adathozzáférési rétegként hozzárendeljük.
Például néhány barát úgy érzi, hogy a BLL réteg nem jelentős, de egyszerűen feltöltik a DAL adatokat, és továbbítják a felhasználói felületre anélkül, hogy bármilyen feldolgozást végeznének. Nézd meg ezt a példát
BLL réteg
SelectUser(UserInfo userInfo) a felhasználónév vagy e-mail alapján kapja meg a felhasználói adatokat.
Az IsExist(UserInfo userInfo) határozza meg, hogy létezik-e a megadott felhasználónév vagy e-mail cím.
Ezután a DAL megadja a BLL híváshoz szükséges megfelelő módszert is
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Így a BLL csak a sugárzási szerepet tölti be.
De ha igen:
BLL. IsExist(Userinfo userinfo)
{
UerInfo felhasználó = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Ekkor a DAL-nak nem kell megvalósítania az IsExist() metódust, és a BLL-ben logikai feldolgozási kód van.
3、UserModel.cs
Entitás, ez a dolog, azt gondolhatod, hogy nem könnyű rétegezni. Engem is beleértve, így értettem: UI?àModel?àBLL?àModel?àDAL, így úgy vélik, hogy a Modell hidatként működik a rétegek közötti adatátvitelhez. De itt nem egyszerűségre gondolunk, hanem a komplexitásra.
Mi az a modell? Semmiség! Ez elengedhetetlen egy háromszintes architektúrában. Ez valójában a legalapvetőbb dolog az objektumorientált programozásban: az osztályok. A táblázat egy osztály, egy hír is egy osztály, az int, string, doublie stb. is osztályok, ez csak egy osztály.
Így a modell helyzete a háromrétegű architektúrában megegyezik az olyan változók állapotával, mint az int és a string, és nincs más célja, csak adattárolásra használják, de összetett adatokat tárol. Ezért, ha a projektben lévő objektumok nagyon egyszerűek, akkor közvetlenül átadhatsz több paramétert modell nélkül, így háromrétegű architektúrát hozhatsz létre.
Miért van szükséged egy modellre, és mik az előnyei? Az alábbiakban jut eszembe, amikor egy itt beillesztett kérdésre gondolkodnak:
A modell nagyobb szerepet játszhat a paraméterek átadásában minden rétegen?
Paraméterek átadásakor a következőket teheted:
AddUser(userId,userName,userPassword,...,)
Ez így is lehet:
AddUser(userInfo)
Melyik a két módszer közül jobb? Első pillantásra ez a második sokkal jobb lehet.
Mikor kell paramétereket átadni a normál változó típusok (int, string, guid, double) rétegek között, és mit kell átadni a modell segítségével? A következő módszerek:
SelectUser(int UserId)
SelectUserByName(string felhasználónév)
SelectUserByName(string username, string password)
SelectUserByEmail (string email)
SelectUserByEmail (string email, string password)
Összefoglalható a következőként:
SelectUser(userId)
SelectUser(user)
Itt a felhasználói modell objektumot használjuk, hogy négy kombinációs módot tartalmazzunk: felhasználónév, jelszó és e-mail (felhasználónév), jelszó és e-mail (felhasználónév) módot. A UserId is össze lehet olvasztani a felhasználóval, de a projekt többi BLL is azonosító paraméterekkel rendelkező interfészeket valósít meg, így ez az elem is megmarad.
A userInfo átkerült, szóval hogyan kezeljük ezt, ennek sorrendben kell lennie, van egy konkrét kód, amit el kell dönteni.
Itt a sorrendben dolgozzák fel
Először nézd meg, hogy megvan-e a felhasználóneved és a jelszavod, aztán megvan-e e-mail és jelszó, aztán van-e felhasználóneved, és aztán van-e e-mail címed. Sorrendben dolgozzák fel.
Így, ha a jövőben új tartalom kerül hozzá, például a tagsági kártyát (számot), nincs szükség az interfész megváltoztatására, csak a DAL kódban a szám támogatását kell hozzáadni, majd a tagságkártya tartalmának teljesítményét és feldolgozását az előtérbe helyezni.
4、UserDAL.cs
public IList SelectUsers(): Minden felhasználói információ listáját adja vissza
public UserInfo SelectUser(int UserId): Visszaadja a megadott felhasználó megbízható adatait
public bool InsertUser(UserInfo User): Felhasználói adatok hozzáadva
public bool UpdateUser(UserInfo User): Frissíti a felhasználói adatokat
public void DeleteUser(int UserId): Eltávolítja a felhasználói adatokat
Amit sokan nem tudnak a legjobban megfejteni, az az adathozzáférési réteg, mely része számít adathozzáférési rétegnek? Egyesek úgy gondolják, hogy az adatbázis az adathozzáférési réteg, ami nem egyértelmű a definíciójában, a DAL az adathozzáférési réteg, nem pedig az adattároló réteg, így az adatbázis nem lehet ez a réteg. Az SQLHelper szerepe az ismétlődő kódolás csökkentése és a kódolás hatékonyságának javítása, így ha hozzászoktam ahhoz, hogy törődöm a hatékonysággal vagy nem adatbázis adatforrást használok, el tudom dobni az SQLHelpert, egy olyan részt, amit bármikor el lehet dobni, hogyan válhat a háromrétegű architektúra rétegévé.
A következőképpen definiálható: az adatforrás-műveletekhez kapcsolódó kódot az adathozzáférési rétegbe kell helyezni, amely az adathozzáférési réteghez tartozik
5、IUserDAL
Az adathozzáférési réteg interfész is felejthetetlen dolog, mert a Petshop hozza magával a ClassFactory és a ClassFactory is, így néhány projekt ezt a két dolgot megteszi, függetlenül attól, hogy több adatforrást kell támogatniuk vagy sem, mások pedig még nem is építenek ClassFactoryt, csak az IDAL-t, majd "IUserDAL iUserDal = új UserDAL(); Nem tudom, mi a jelentése. Ez teljesen egy tigris, nem egy kutyaellenes.
Sokan félreértik ezt, hogy létezik ilyen kapcsolat: BLL?àIDAL?àDAL, azt gondolva, hogy az IDAL hídként működik a BLL és a DAL között, míg a BLL IDAL-on keresztül hívja a DAL-t. De a valóság az, hogy még ha így is kódolnád: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Amikor a "iUserDal.SelectUsers()" végrehajtása során valójában a UserDAL példány hajt végre, nem az IUserDAL példány, így az IDAL pozíciója a harmadik rétegben a DAL szinthez kapcsolódik.
A fenti bevezetés révén a háromszintű építészet hierarchiája alapvetően megmagyarázható. Valójában van egy módszerem arra, hogy megítéljem, a háromrétegű architektúra szabványos-e, vagyis ha bármelyik réteg teljesen kicseréljük, az nem befolyásolja a másik két réteget, és egy ilyen struktúra lényegében megfelel a háromréteges szabványnak (bár nehezebb ^_^ megvalósítani). Például, ha a projektet B/S-ről C/S-re változtatod (vagy fordítva), akkor a BLL és DAL nem szükséges változtatni, kivéve a felhasználói felületet; Vagy cseréld az SQLServert Oracle-ra, csak cseréld le SQLServerDAL-t OracleDAL-ra, további műveletek nem szükségesek, stb. Eredetileg egy konkrét kódot akartam hozzáadni a cikkhez, de nem érzem szükségesnek, ha te úgy érzed, hogy szükséges, hozzáadom.
Összefoglaló: Ne gondold, hogy egy réteg felesleges csak azért, mert számodra haszontalan, vagy különösen egyszerű megvalósítani, vagy hagyd el, vagy más célokra használd. Amíg a rétegeket megvalósítják, függetlenül attól, hány réteg van, minden rétegnek egyértelmű céllal és funkciós megvalósításával kell rendelkeznie, és nem szabad befolyásolni a tényleges folyamat, így ugyanaz a fájltípus különböző rétegekben található. Ne hagyd, hogy ugyanaz a réteg különböző funkciókat valósítson meg. |
Közzétéve 2015. 05. 07. 10:53:35
|
|
|
