BLL ist die Business Logic Layer
DAL steht für Data Access Layer
Dreistufige Architektur von ASP.NET (DAL, BLL, UI)
Grafiken stellen eine dreischichtige Struktur dar. Das Web ist die USL-Schicht
Web –> BLL –> Al
| | |
| V |
+–> Modell <—+
1. Dreistufige Architektur
1. Präsentationsschicht (USL): Sie stellt hauptsächlich die WEB-Methode dar, kann aber auch als WINFORM-Modus ausgedrückt werden. Wenn die Logikschicht sehr robust und gut etabliert ist, wird sie unabhängig davon, wie die Performance-Schicht definiert und verändert wird, perfekt funktionieren.
2. Geschäftslogikschicht (BLL): Hauptsächlich für spezifische Probleme kann sie auch als der Betrieb der Datenschicht und die logische Verarbeitung von Datengeschäften verstanden werden. Wenn die Datenschicht die Bausteine ist, dann ist die Logikschicht der Baustein.
3. Datenzugriffsschicht (DAL): Sie handelt sich hauptsächlich um die Operationsschicht der Originaldaten (in Form einer Datenbank, Textdatei oder einer anderen Form der Datenspeicherung), und nicht die Originaldaten, also die Funktionsweise der Daten, nicht der Datenbank, insbesondere der Geschäftslogikschicht oder der Präsentationsschicht
Bereitstellung von Datendienstleistungen.
2. Spezifische Unterscheidung
1. Präsentationsschicht: akzeptiert hauptsächlich die Anfrage des Benutzers und liefert Daten zurück, wodurch der Client Zugriff auf die Anwendung erhält.
2. Geschäftslogikschicht: hauptsächlich verantwortlich für den Betrieb der Datenschicht, also die Kombination einiger Datenschichtoperationen.
3. Datenzugriffsschicht: Es hängt hauptsächlich davon ab, ob Ihre Datenschicht logische Verarbeitung enthält; tatsächlich führen ihre Funktionen hauptsächlich verschiedene Operationen auf der Datendatei aus und müssen sich keine weiteren Operationen beschäftigen.
3. Zusammenfassung
Die dreischichtige Struktur ist ein streng hierarchischer Ansatz, das heißt, die Datenzugriffsschicht (DAL) kann nur von der Business Logic Layer (BLL) erreicht werden, und die Business Logic Layer nur von der Präsentationsschicht (USL). Einige dreischichtige Strukturen fügen auch weitere Ebenen wie Factory und Model hinzu, die tatsächlich eine Erweiterung und Anwendung auf Basis dieser drei Schichten darstellen.
Ein einfaches dreischichtiges Programm umfasst in der Regel mehrere Projekte des DAL-BLL WEB-Modells, deren gegenseitige Referenzen wie folgt sind
1) WEB-Referenzen BLL, Modell
2) BLL bezieht sich auf DAL, Modell
3) DAL bezieht sich auf das Modell
4) Das Modell hat keine Zitate
Wenn es um die dreistufige Architektur geht, weiß jeder, dass es sich um die Performance Layer (UI), die Business Logic Layer (BLL) und die Data Access Layer (DAL) handelt, und es gibt viele Möglichkeiten, jede Schicht zu unterteilen. Aber wie man den spezifischen Code schreibt und in welcher Schicht diese Dateien gezählt werden, ist unklar. Das Folgende ist ein einfaches Beispiel, um Sie zu einem dreistufigen Architekturprojekt zu führen; dieses Beispiel hat nur eine Funktion, nämlich die einfache Verwaltung der Benutzer.
Zuerst erstelle eine leere Lösung und füge die folgenden Elemente und Dateien hinzu
1. Ein ASP.NET Web Application-Projekt hinzufügen, es UI nennen und eine neue Web Form-Datei User.aspx erstellen (einschließlich User.aspx.cs)
2. Ein ClassLibrary-Projekt hinzufügen, es BLL nennen und eine neue Class-Datei erstellen UserBLL.cs
3. Ein ClassLibrary-Projekt hinzufügen, es DAL nennen und eine neue Class-Datei UserDAL.cs erstellen. Fügen Sie eine SQLHelper-Referenz hinzu. (Dies ist Microsofts Datenzugriffsklasse, oder Sie können den gesamten Datenzugriffscode direkt schreiben.) Ich benutze normalerweise die DataAccessHelper-Klasse, die ich schreibe.
4. Ein ClassLibrary-Projekt hinzufügen, es Model nennen und eine neue Class-Typ-Datei UserModel.cs
5. Ein ClassLibrary-Projekt hinzufügen, es IDAL nennen und eine neue Interface-Datei IUserDAL.cs
6. Ein ClassLibrary-Projekt hinzufügen und es ClassFactory nennen
Ich glaube, Sie haben gesehen, dass dies sich nicht vom Beispiel von Petshop unterscheidet, und es ist einfacher, weil ich die dreischichtige Architektur auch durch Petshop lerne. Allerdings sind manche Freunde vielleicht vage bezüglich des Umfangs dieser Projekte und der Beziehung zwischen ihnen, hier eine Erklärung einzeln:
1. User.aspx und User.aspx.cs
Sowohl Dokumente als auch die Elemente, zu denen die Datei gehört, sowie darunter werden nicht wiederholt) sind Teil der Präsentationsschicht. User.aspx ist leichter zu verstehen, weil es sich um eine Anzeigeseite handelt. User.aspx.cs manche Leute denken, dass es nicht gezählt, sondern in die Geschäftslogik-Schicht aufgenommen werden sollte. Wenn du kein Layering machst, ist es kein Problem, User.aspx.cs die Geschäftslogik verwalten und sogar die Datenbank bedienen zu lassen, aber wenn du Layering machst, sollte das nicht gemacht werden. In einer hierarchischen Struktur sollten User.aspx.cs nur Inhalte im Zusammenhang mit der Präsentation behandeln, und sonst sollte nichts abgedeckt werden.
Wenn wir zum Beispiel die Funktion implementieren, Benutzer in Form einer Liste anzuzeigen, wird die Arbeit der Informationsextraktion von BLL erledigt, und nachdem die UI (in diesem Fall User.aspx.cs sie ) BLL aufruft, um UserInfo zu erhalten, ist sie durch Code an die Datensteuerung des User.aspx gebunden, um die Anzeige der Liste zu realisieren. In diesem Prozess spielt User.aspx.cs es keine Rolle in der Benutzeroberfläche, sondern dient nur dazu, Daten zu übertragen, und da der Großteil des eigentlichen Codes so implementiert ist, sind manche der Meinung, dass User.aspx.cs nicht als UI gezählt werden sollte, sondern für die logische Verarbeitung in BLL integriert werden sollte. Im weiteren Sinne wurde eine neue Anforderung eingeführt, jedem Nutzer ein Symbol hinzuzufügen, das das Geschlecht des Nutzers lebendig darstellt, und für Personen unter 18 Jahren wurde es durch ein Kindersymbol dargestellt. Die Verwirklichung dieser Anforderung ist die Wendung des User.aspx.cs, und in diesem Fall User.aspx.cs hat sie einen echten Nutzen.
2、NewBLL.cs
Fügen Sie die folgenden Methoden hinzu:
öffentliches IList GetUsers(): Gibt eine Liste aller Benutzerinformationen zurück
public UserInfo GetUser(int UserId): Gibt die Daten des angegebenen Benutzers zurück
öffentlicher bool AddUser(UserInfo User): Hinzugefügte Benutzerinformationen
public bool ChangeUser(UserInfo User): Aktualisiert Benutzerinformationen
public void RemoveUser(int UserId): Entfernt Benutzerinformationen
Diese Datei gehört zur Business Logic Layer und ist speziell für die Verarbeitung von Operationen im Zusammenhang mit Business Logic vorgesehen. Viele Menschen denken vielleicht, dass diese Schicht nur dazu dient, die Daten von der Leistungsschicht auf die Datenschicht weiterzuleiten. Es gibt tatsächlich viele solcher Fälle, aber das kann nur bedeuten, dass das Projekt relativ einfach ist oder die Beziehung zwischen dem Projekt selbst und dem Geschäft nicht eng integriert ist (wie beim derzeit beliebten MIS), sodass die Geschäftsebene nichts zu tun hat und lediglich eine Weiterleitungsrolle spielt. Das bedeutet jedoch nicht, dass die Geschäftsebene entbehrlich ist; je größer das Projekt wird oder es mehr Geschäftsbeziehungen gibt, desto mehr wird die Geschäftsebene ihre Rolle widerspiegeln.
Der wahrscheinlichste Fehler besteht darin, den Datenoperationscode der Geschäftslogikschicht zuzuweisen und der Datenbank die Datenzugriffsschicht.
Zum Beispiel finden einige Freunde, dass die BLL-Ebene nicht sinnvoll ist, laden aber einfach die DAL-Daten hoch und leiten sie ohne Verarbeitung an die Benutzeroberfläche weiter. Schauen Sie sich dieses Beispiel an
BLL-Schicht
SelectUser(UserInfo userInfo) erhält die Benutzerdaten basierend auf dem Benutzernamen oder der E-Mail, die eingeht.
IsExist(UserInfo userInfo) bestimmt, ob der angegebene Benutzername oder die E-Mail-Adresse existiert.
Dann stellt der DAL auch die entsprechende Methode für den GLL-Aufruf bereit
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
Auf diese Weise spielt BLL nur eine Übertragungsrolle.
Aber falls ja:
BLL. IsExist(Userinfo userinfo)
{
UerInfo-Nutzer = DAL. SelectUser(Benutzer);
zurückkehren (userInfo.Id != null);
}
Dann muss DAL die IsExist()-Methode nicht implementieren, und es gibt logischen Verarbeitungscode in BLL.
3、UserModel.cs
Entität, dieses Ding, du denkst vielleicht, es ist nicht einfach zu stratifizieren. Mich eingeschlossen verstand ich es so: UI?àModel?àBLL?àModel?àDAL, daher wird angenommen, dass das Modell als Brücke für die Datenübertragung zwischen den Schichten fungiert. Aber hier denken wir nicht über Dinge einfach, sondern über Komplexität.
Was ist Model? Es ist nichts! Sie ist in einer dreistufigen Architektur entbehrlich. Es ist tatsächlich das Grundlegendste in der objektorientierten Programmierung: Klassen. Eine Tabelle ist eine Klasse, eine News ist auch eine Klasse, Int, String, Doublie usw. sind ebenfalls Klassen, es ist einfach eine Klasse.
Auf diese Weise ist die Position des Modells in der dreischichtigen Architektur identisch mit dem Status von Variablen wie int und String, und es hat keinen anderen Zweck, es wird nur zur Datenspeicherung verwendet, speichert aber komplexe Daten. Wenn die Objekte in Ihrem Projekt also sehr einfach sind, können Sie mehrere Parameter direkt ohne Modell weitergeben, um eine dreischichtige Architektur zu erstellen.
Warum braucht man also ein Modell und welche Vorteile hat es? Das Folgende ist das, was einem beim Nachdenken über eine hier eingefügte Frage einfällt:
Kann das Modell eine größere Rolle beim Weitergeben von Parametern auf jeder Ebene spielen?
Beim Übergeben von Parametern zwischen den Schichten können Sie Folgendes tun:
AddUser(userId, Benutzername, BenutzerPasswort,...,)
Es kann auch so aussehen:
AddUser(userInfo)
Welche dieser beiden Methoden ist besser? Auf den ersten Blick muss es das zweite Exemplar deutlich besser sein.
Wann sollte man Parameter zwischen Schichten mit normalen Variablentypen (int, String, Guid, Double) übergeben und was sollte man mit Model weitergeben? Die folgenden Methoden:
SelectUser(int UserId)
SelectUserByName (Zeichenketten-Benutzername)
SelectUserByName(Zeichenzeichen-Benutzername, Zeichenzeichen-Passwort)
SelectUserByEmail (String-E-Mail)
SelectUserByEmail (String-E-Mail, String-Passwort)
Es lässt sich wie folgt zusammenfassen:
SelectUser(userId)
SelectUser(user)
Hier verwenden wir das User Model Object, um vier Kombinationsmodi – Benutzername, Passwort und E-Mail – einzuschließen. UserId kann ebenfalls in user integriert werden, aber andere BLL im Projekt implementieren Schnittstellen mit ID-Parametern, sodass auch dieses Element erhalten bleibt.
userInfo wird weitergegeben, also wie man damit umgeht? Das muss in der Reihenfolge erfolgen, es gibt einen speziellen Code zu entscheiden.
Hier wird es in folgender Reihenfolge verarbeitet
Schau zuerst, ob du sowohl Benutzername als auch Passwort hast, dann ob du sowohl E-Mail als auch Passwort hast, dann ob du einen Benutzernamen hast, und dann ob du E-Mail hast. Wird nacheinander bearbeitet.
Auf diese Weise ist bei einem neuen Inhalt, also der Mitgliedskarte (Nummer), nicht notwendig, die Schnittstelle zu ändern, sondern nur Unterstützung für die Nummer im DAL-Code hinzuzufügen und dann die Leistung und Verarbeitung des Mitgliedskarteninhalts im Vordergrund zu setzen.
4、UserDAL.cs
öffentliches IList SelectUsers(): Gibt eine Liste aller Benutzerinformationen zurück
public UserInfo SelectUser(int UserId): Gibt die vertrauenswürdigen Informationen des angegebenen Benutzers zurück
öffentlicher bool InsertUser(UserInfo User): Hinzugefügte Benutzerinformationen
public bool UpdateUser(UserInfo User): Aktualisiert Benutzerinformationen
public void DeleteUser(int UserId): Entfernt Benutzerinformationen
Was viele Leute am meisten nicht herausfinden können, ist die Datenzugriffsschicht – welcher Teil gilt als Datenzugriffsschicht? Manche Leute denken, dass die Datenbank die Datenzugriffsschicht ist, was die Definition nicht klar ist; DAL ist die Datenzugriffsschicht und nicht die Datenspeicherschicht, daher kann die Datenbank nicht diese Schicht sein. Die Aufgabe von SQLHelper besteht darin, wiederholtes Programmieren zu reduzieren und die Codiereffizienz zu verbessern. Wenn ich also Wert auf Effizienz oder eine nicht-datenbankbasierte Datenquelle gewöhnt bin, kann ich SQLHelper verwerfen – einen Teil, der man nach Belieben wegwerfen kann, wie kann es zu einer Schicht der dreischichtigen Architektur werden?
Er kann wie folgt definiert werden: Der Code, der mit den Datenquellenoperationen zusammenhängt, sollte in die Datenzugriffsschicht gelegt werden, die zur Datenzugriffsschicht gehört
5、IUserDAL
Die Datenzugriffsschicht-Schnittstelle ist ebenfalls entbehrlich, weil Petshop sie und die ClassFactory-Fabrik mitbringt, sodass einige Projekte diese beiden Dinge unabhängig davon machen, ob sie mehrere Datenquellen unterstützen müssen oder nicht, und manche bauen ClassFactory nicht einmal, sondern nur IDAL, und dann "IUserDAL iUserDal = neuer UserDAL(); Ich weiß nicht, was das bedeutet. Das ist komplett ein Tiger und kein Anti-Hund.
Viele Menschen haben hier ein Missverständnis, nämlich dass es eine solche Beziehung gibt: BLL?àIDAL?àDAL, in der Annahme, dass IDAL als Brücke zwischen BLL und DAL dient, und BLL ruft DAL über IDAL an. Aber die Realität ist, dass selbst wenn man es so programmiert: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Beim Ausführen von "iUserDal.SelectUsers()" wird tatsächlich die UserDAL-Instanz ausgeführt, nicht die IUserDAL-Instanz, sodass die Position von IDAL in der dritten Schicht mit der DAL-Ebene zusammenhängt.
Durch die obige Einführung wird die Hierarchie der dreistufigen Architektur im Wesentlichen erklärt. Tatsächlich habe ich eine Möglichkeit zu beurteilen, ob die Drei-Schicht-Architektur Standard ist, das heißt, das vollständige Ersetzen einer der drei Schichten wirkt sich nicht auf die anderen beiden Schichten aus, und eine solche Struktur erfüllt im Grunde den Drei-Schicht-Standard (obwohl er schwieriger ^_^ umzusetzen ist). Wenn du zum Beispiel das Projekt von B/S auf C/S änderst (oder umgekehrt), müssen BLL und DAL außer der Benutzeroberfläche nicht geändert werden; Oder ändere SQLServer zu Oracle, ersetze einfach SQLServerDAL durch OracleDAL, es sind keine weiteren Operationen erforderlich, usw. Ursprünglich wollte ich dem Artikel einen bestimmten Code hinzufügen, aber ich halte das nicht für notwendig. Wenn du es für notwendig hältst, werde ich ihn hinzufügen.
Zusammenfassung: Denken Sie nicht, dass eine Ebene unnötig ist, nur weil sie für Sie nutzlos ist, besonders einfach umzusetzen, aufzugeben, oder für andere Zwecke zu verwenden. Solange die Schichten ausgeführt werden, egal wie viele Schichten es gibt, muss jede Schicht einen klaren Zweck und eine funktionale Realisierung haben und darf nicht vom eigentlichen Prozess beeinflusst werden, sodass derselbe Dateityp in verschiedenen Schichten untergebracht wird. Lass nicht zu, dass dieselbe Schicht unterschiedliche Funktionen implementiert. |
Veröffentlicht am 07.05.2015 10:53:35
|
|
|
