BLL is de Business Logic Layer
DAL is Data Access Layer
Drielaagse architectuur van ASP.NET (DAL, BLL, UI)
Graphics vormen een structuur van drie lagen. Het web is de USL-laag
Web –> BLL –> DAL.
| | |
| V |
+–> model <—+
1. Drielaagse architectuur
1. Presentatielaag (USL): Deze vertegenwoordigt voornamelijk de WEB-methode, maar kan ook worden uitgedrukt als WINFORM-modus. Als de logische laag vrij robuust en goed gevestigd is, zal deze perfect functioneren, ongeacht hoe de prestatielaag wordt gedefinieerd en aangepast.
2. Bedrijfslogicalaag (BLL): voornamelijk voor specifieke problemen kan het ook worden begrepen als de werking van de datalaag en de logische verwerking van datazaken. Als de datalaag de bouwstenen is, dan is de logische laag de bouwsteen.
3. Data access layer (DAL): Dit is voornamelijk de operationele laag van de originele data (in de vorm van een database, tekstbestand of een andere vorm van gegevensopslag), en niet de originele data, dat wil zeggen de werking van de data, niet de database, specifiek de business logic layer of de presentatielaag
Levering van data-diensten.
2. Specifiek onderscheid
1. Presentatielaag: accepteert voornamelijk het verzoek van de gebruiker en levert data terug, waardoor de client toegang krijgt tot de applicatie.
2. Bedrijfslogicalaag: voornamelijk verantwoordelijk voor de werking van de datalaag, dat wil zeggen de combinatie van bepaalde datalaagoperaties.
3. Data-toegangslaag: Het hangt vooral af of je datalaag logische verwerking bevat; in feite voeren de functies vooral verschillende bewerkingen op het databestand uit en hoeven je je geen zorgen te maken over andere bewerkingen.
3. Samenvatting
De drielaagse structuur is een strikte hiërarchische aanpak, dat wil zeggen dat de data-toegangslaag (DAL) alleen toegankelijk is door de business logic layer (BLL), en de business logic layer alleen toegankelijk is door de presentatielaag (USL). Sommige drielaagse structuren voegen ook andere lagen toe zoals Factory en Model, die eigenlijk een uitbreiding en toepassing zijn op basis van deze drie lagen.
Een eenvoudig drielaags programma omvat doorgaans meerdere projecten van het DAL BLL WEB MODEL, en hun wederzijdse referenties zijn als volgt
1) WEB-referenties BLL, Model
2) BLL verwijst naar DAL, Model
3) DAL verwijst naar het Model
4) Het model heeft geen citaties
Als het gaat om de drielaagse architectuur, weet iedereen dat het de prestatielaag (UI), de business logic laag (BLL) en de data access layer (DAL) is, en er zijn veel manieren om elke laag te onderververdelen. Maar hoe je de specifieke code schrijft en in welke laag die bestanden worden geteld, is vaag. Het volgende is een eenvoudig voorbeeld om je te leiden naar het beoefenen van een drielaags architectuurproject; dit voorbeeld heeft slechts één functie, namelijk eenvoudig beheer van gebruikers.
Maak eerst een lege oplossing en voeg de volgende items en bestanden toe
1. Voeg een ASP.NET Web Application-project toe, noem het UI en maak een nieuw Web Form-bestand aan User.aspx (inclusief User.aspx.cs)
2. Voeg een ClassLibrary-project toe, noem het BLL en maak een nieuw Class-bestand aan UserBLL.cs
3. Voeg een ClassLibrary-project toe, noem het DAL, en maak een nieuw Class-bestand UserDAL.cs. Voeg een SQLHelper-referentie toe. (Dit is Microsofts data-toegangsklasse, of je kunt alle data-toegangscode direct schrijven.) Ik gebruik meestal de DataAccessHelper-klasse die ik schrijf).
4. Voeg een ClassLibrary-project toe, noem het Model en maak een nieuw Class-type bestand UserModel.cs
5. Voeg een ClassLibrary-project toe, noem het IDAL en maak een nieuw Interface-bestand IUserDAL.cs
6. Voeg een ClassLibrary-project toe en noem het ClassFactory.
Ik geloof dat je hebt gezien dat dit niet verschilt van het voorbeeld van Petshop, en het is eenvoudiger, omdat ik ook de drielaagse architectuur via Petshop leer. Sommige vrienden kunnen echter vaag zijn over het niveau van deze projecten en de relatie ertussen; hier volgt een uitleg van ze één voor één:
1. User.aspx en User.aspx.cs
Zowel documenten (als de items waartoe het bestand behoort, evenals daaronder, worden niet herhaald) maken deel uit van de presentatielaag. User.aspx is makkelijker te begrijpen omdat het een weergavepagina is. User.aspx.cs sommigen vinden dat het niet meegeteld moet worden, maar wel in de business logic-laag moet worden opgenomen. Als je geen layering doet, is het geen probleem om User.aspx.cs de bedrijfslogica te laten beheren en zelfs de database te laten beheren, maar als je layering doet, zou dit niet moeten gebeuren. In een hiërarchische structuur zou User.aspx.cs alleen inhoud moeten behandelen die met weergave te maken heeft, en verder zou niets moeten worden behandeld.
Als we bijvoorbeeld de functie implementeren om gebruikers in de vorm van een lijst te tonen, dan wordt het werk van het extraheren van informatie gedaan door BLL, en nadat de UI (in dit geval User.aspx.cs het geval is) BLL aanroept om UserInfo te verkrijgen, is deze gebonden aan de datacontrole van de User.aspx via code om de weergave van de lijst te realiseren. In dit proces speelt het User.aspx.cs geen rol in de UI, het wordt alleen gebruikt om data door te geven, en omdat het grootste deel van de daadwerkelijke codering zo is geïmplementeerd, vinden sommigen dat User.aspx.cs niet als UI moet worden geteld, maar in BLL moet worden samengevoegd voor logische verwerking. Verder werd er een nieuwe eis gesteld om een icoon voor elke gebruiker toe te voegen om het geslacht van de gebruiker levendig weer te geven, en voor mensen jonger dan 18 jaar werd dit weergegeven door een kindicoon. De realisatie van deze vereiste is de beurt van User.aspx.cs, en in dit geval User.aspx.cs het een echt nut.
2、NewBLL.cs
Voeg de volgende methoden toe:
publieke IList GetUsers(): Geeft een lijst van alle gebruikersinformatie terug
publieke UserInfo GetUser(int UserId): Geeft de gegevens van de opgegeven gebruiker terug
publieke bool AddUser(UserInfo User): Toegevoegde gebruikersinformatie
publieke bool ChangeUser(UserInfo User): Werkt gebruikersinformatie bij
public void RemoveUser(int UserId): Verwijdert gebruikersinformatie
Dit bestand behoort tot de bedrijfslogicalaag en is bedoeld voor het afhandelen van operaties gerelateerd aan businesslogica. Veel mensen denken misschien dat het enige nut van deze laag is om de data van de prestatielaag naar de datalaag te sturen. Er zijn inderdaad veel van zulke gevallen, maar dit kan alleen betekenen dat het project relatief eenvoudig is, of dat de relatie tussen het project zelf en het bedrijf niet nauw geïntegreerd is (zoals bij de huidige populaire MIS), waardoor de bedrijfslaag niets te maken heeft en alleen een doorstuurrol speelt. Maar dit betekent niet dat de bedrijfslaag overbodig is; naarmate het project groeit of er meer zakelijke relaties ontstaan, zal de bedrijfslaag haar rol weerspiegelen.
De meest waarschijnlijke fout hier is om de data-operatiecode toe te wijzen aan de business logic-laag en de database als data-toegangslaag.
Sommige vrienden vinden bijvoorbeeld dat de BLL-laag niet betekenisvol is, maar ze uploaden gewoon de DAL-data en sturen die zonder verwerking door naar de UI. Kijk eens naar dit voorbeeld
BLL-laag
SelectUser(UserInfo userInfo) krijgt de gebruikersgegevens op basis van de gebruikersnaam of het e-mailadres dat binnenkomt.
IsExist(UserInfo userInfo) bepaalt of de opgegeven gebruikersnaam of e-mailadres bestaat.
Dan biedt de DAL ook de bijbehorende methode voor de BLL-aanroep
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Op deze manier speelt BLL alleen een transmissierol.
Maar als je dat doet:
BLL. IsExist(Userinfo userinfo)
{
UerInfo-gebruiker = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Dan hoeft DAL de IsExist()-methode niet te implementeren, en is er logische verwerkingscode in BLL.
3、UserModel.cs
Entiteit, dit ding, je denkt misschien dat het niet makkelijk is om te stratificeren. Inclusief mijzelf begreep ik het als volgt: UI?àModel?àBLL?àModel?àDAL, dus men gelooft dat het Model fungeert als een brug voor datatransmissie tussen de lagen. Maar hier denken we niet aan eenvoudige, maar aan complexiteit.
Wat is model? Het is niets! Het is overbodig in een drielaagse architectuur. Het is eigenlijk het meest basale in objectgeoriënteerd programmeren: klassen. Een tabel is een klasse, een news is ook een klasse, int, string, doublie, enzovoort zijn ook klassen, het is gewoon een klasse.
Op deze manier is de positie van het model in de drielaagse architectuur hetzelfde als de status van variabelen zoals int en string, en het heeft geen ander doel; het wordt alleen gebruikt voor gegevensopslag, maar slaat complexe data op. Daarom, als de objecten in je project heel eenvoudig zijn, kun je direct meerdere parameters doorgeven zonder model om een drielaagse architectuur te creëren.
Dus waarom heb je een model nodig, en wat zijn de voordelen? Het volgende is wat in me opkomt bij het nadenken over een vraag, hier ingevoegd:
Kan het Model een grotere rol spelen bij het doorgeven van parameters op elke laag?
Bij het doorgeven van parameters tussen lagen kun je het volgende doen:
AddUser(userId,userName,userPassword,...,)
Het kan ook zo zijn:
AddUser(userInfo)
Welke van deze twee methoden is beter? Op het eerste gezicht moet het de tweede zijn, veel beter.
Wanneer moet je parameters doorgeven tussen lagen met normale variabeletypes (int, string, guid, double), en wat moet je doorgeven met Model? De volgende methoden:
SelectUser(int UserId)
SelectUserByName(string gebruikersnaam)
SelectUserByName(tekenwijzernaam, wachtwoord voor reeks)
SelectUserByEmail (string e-mail)
SelectUserByEmail(string e-mail, string wachtwoord)
Het kan worden samengevat als:
SelectUser(userId)
SelectUser(user)
Hier gebruiken we het user model object om vier combinatiemodi te combineren: gebruikersnaam, wachtwoord en e-mail. UserId kan ook worden samengevoegd met user, maar andere BLL in het project implementeren interfaces met id-parameters, dus dit item wordt ook behouden.
userInfo wordt doorgegeven, dus hoe je ermee om gaat? Dit moet in volgorde van volgorde zijn, er is een specifieke code om te bepalen.
Hier wordt het in deze volgorde verwerkt
Kijk eerst of je zowel gebruikersnaam als wachtwoord hebt, kijk dan of je zowel e-mail als wachtwoord hebt, kijk of je een gebruikersnaam hebt, en kijk daarna of je e-mail hebt. Achtereenvolgens verwerkt.
Op deze manier, als in de toekomst een nieuwe inhoud wordt toegevoegd, namelijk de lidmaatschapskaart (nummer), is het niet nodig om de interface te wijzigen, alleen ondersteuning voor het nummer in de DAL-code toe te voegen, en vervolgens de prestaties en verwerking van de lidmaatschapskaartinhoud op de voorgrond te plaatsen.
4、UserDAL.cs
publieke IList SelectUsers(): Geeft een lijst van alle gebruikersinformatie terug
publieke UserInfo SelectUser(int UserId): Geeft de vertrouwde informatie van de opgegeven gebruiker terug
publieke bool InsertUser(UserInfo User): Toegevoegde gebruikersinformatie
publieke bool UpdateUser(UserInfo User): Werkt gebruikersinformatie bij
public void DeleteUser(int UserId): Verwijdert gebruikersinformatie
Wat veel mensen het meest kunnen achterhalen is de data-toegangslaag, welk deel wordt beschouwd als de data-toegangslaag? Sommige mensen denken dat de database de datatoegangslaag is, wat niet duidelijk is over de definitie; DAL is de datatoegangslaag in plaats van de dataopslaglaag, dus de database kan niet deze laag zijn. De rol van SQLHelper is om repetitief coderen te verminderen en de codeerefficiëntie te verbeteren, dus als ik gewend ben om efficiëntie te geven of een niet-database-databron te gebruiken, kan ik SQLHelper weggooien, een onderdeel dat naar wens kan worden weggegooid, hoe kan het dan een laag worden van de drielaagse architectuur?
Deze kan als volgt worden gedefinieerd: de code die betrekking heeft op databronoperaties moet worden geplaatst in de data-toegangslaag, die tot de data-toegangslaag behoort
5、IUserDAL
De data-toegangslaaginterface, dit is ook een onvermijdelijk iets, omdat Petshop het en ClassFactory met zich meebrengt, dus sommige projecten doen deze twee dingen ongeacht of ze meerdere databronnen moeten ondersteunen of niet, en sommige bouwen zelfs geen ClassFactory maar alleen IDAL, en dan "IUserDAL iUserDal = nieuwe UserDAL(); Ik weet niet wat de betekenis is. Dit is volledig een tijger en geen anti-hond.
Veel mensen hebben hier een misvatting, namelijk dat er zo'n relatie is: BLL?àIDAL?àDAL, denkend dat IDAL fungeert als een brug tussen BLL en DAL, en BLL roept DAL via IDAL. Maar de realiteit is dat zelfs als je het zo codeert: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Bij het uitvoeren van "iUserDal.SelectUsers()" wordt eigenlijk de UserDAL-instantie uitgevoerd, niet de IUserDAL-instantie, dus de positie van IDAL in de derde laag is gerelateerd aan het DAL-niveau.
Via bovenstaande inleiding wordt de hiërarchie van de drielaagse architectuur in feite uitgelegd. Sterker nog, ik heb een manier om te beoordelen of de drie-laagse architectuur standaard is, dat wil zeggen, het volledig vervangen van een van de drie lagen zal de andere twee lagen niet beïnvloeden, en zo'n structuur voldoet in feite aan de drie-laagse standaard (hoewel het moeilijker ^_^ te implementeren is). Als je bijvoorbeeld het project verandert van B/S naar C/S (of andersom), hoeven BLL en DAL alleen maar te worden aangepast voor de UI; Of verander SQLServer naar Oracle, vervang gewoon SQLServerDAL door OracleDAL, dan zijn er geen andere bewerkingen nodig, enzovoort. Oorspronkelijk wilde ik wat specifieke code aan het artikel toevoegen, maar ik vind het niet nodig; als jij dat nodig vindt, zal ik het toevoegen.
Samenvatting: Denk niet dat een laag onnodig is alleen omdat hij nutteloos voor je is, of bijzonder eenvoudig te implementeren is, of te laten vallen, of voor andere doeleinden te gebruiken. Zolang de lagen worden uitgevoerd, ongeacht hoeveel lagen er zijn, moet elke laag een duidelijk doel en functionele realisatie hebben, en mag niet worden beïnvloed door het daadwerkelijke proces, waardoor hetzelfde type bestand in verschillende lagen wordt gevonden. Laat niet dezelfde laag verschillende functies implementeren. |
Geplaatst op 07-05-2015 10:53:35
|
|
|
