Το BLL είναι το επίπεδο επιχειρηματικής λογικής
Το DAL είναι επίπεδο πρόσβασης δεδομένων
Αρχιτεκτονική τριών επιπέδων ASP.NET (DAL, BLL, UI)
Τα γραφικά αντιπροσωπεύουν μια δομή τριών επιπέδων. Ο ιστός είναι το επίπεδο USL
ιστός –> bll –> dal
| | |
| V |
+–> μοντέλο <—+
1. Αρχιτεκτονική τριών επιπέδων
1. Επίπεδο παρουσίασης (USL): Αντιπροσωπεύει κυρίως τη μέθοδο WEB, αλλά μπορεί επίσης να εκφραστεί ως λειτουργία WINFORM. Εάν το λογικό επίπεδο είναι αρκετά στιβαρό και καλά εδραιωμένο, θα εξυπηρετήσει τέλεια ανεξάρτητα από το πώς ορίζεται και αλλάζει το επίπεδο απόδοσης.
2. Επίπεδο επιχειρηματικής λογικής (BLL): κυρίως για συγκεκριμένα προβλήματα, μπορεί επίσης να γίνει κατανοητό ως η λειτουργία του επιπέδου δεδομένων και η λογική επεξεργασία της επιχείρησης δεδομένων. Εάν το επίπεδο δεδομένων είναι τα δομικά στοιχεία, τότε το λογικό επίπεδο είναι το δομικό στοιχείο.
3. Επίπεδο πρόσβασης δεδομένων (DAL): Είναι κυρίως το επίπεδο λειτουργίας των αρχικών δεδομένων (με τη μορφή βάσης δεδομένων ή αρχείου κειμένου ή άλλης μορφής αποθήκευσης δεδομένων), παρά τα αρχικά δεδομένα, δηλαδή η λειτουργία των δεδομένων, όχι η βάση δεδομένων, συγκεκριμένα το επίπεδο επιχειρηματικής λογικής ή το επίπεδο παρουσίασης
Παροχή υπηρεσιών δεδομένων.
2. Ειδική διάκριση
1. Επίπεδο παρουσίασης: αποδέχεται κυρίως το αίτημα του χρήστη και επιστρέφει δεδομένα, παρέχοντας στον πελάτη πρόσβαση στην εφαρμογή.
2. Επίπεδο επιχειρηματικής λογικής: κυρίως υπεύθυνο για τη λειτουργία του επιπέδου δεδομένων, δηλαδή τον συνδυασμό ορισμένων λειτουργιών επιπέδου δεδομένων.
3. Επίπεδο πρόσβασης δεδομένων: Εξαρτάται κυρίως από το αν το επίπεδο δεδομένων σας περιέχει λογική επεξεργασία, στην πραγματικότητα, οι λειτουργίες του ολοκληρώνουν κυρίως διάφορες λειτουργίες στο αρχείο δεδομένων και δεν χρειάζεται να ανησυχείτε για άλλες λειτουργίες.
3. Περίληψη
Η δομή τριών επιπέδων είναι μια αυστηρή ιεραρχική προσέγγιση, δηλαδή, το επίπεδο πρόσβασης δεδομένων (DAL) είναι προσβάσιμο μόνο από το επίπεδο επιχειρηματικής λογικής (BLL) και το επίπεδο επιχειρηματικής λογικής είναι προσβάσιμο μόνο από το επίπεδο παρουσίασης (USL). Ορισμένες δομές τριών επιπέδων προσθέτουν επίσης άλλα επίπεδα όπως το Factory και το Model, τα οποία είναι στην πραγματικότητα μια επέκταση και εφαρμογή με βάση αυτά τα τρία επίπεδα.
Ένα απλό πρόγραμμα τριών επιπέδων περιλαμβάνει γενικά πολλά έργα του DAL BLL WEB MODEL και οι αμοιβαίες αναφορές τους είναι οι εξής
1) Αναφορές WEB BLL, Μοντέλο
2) Αναφορές BLL DAL, Μοντέλο
3) Μοντέλο αναφορών DAL
4) Το μοντέλο δεν έχει παραπομπές
Όταν πρόκειται για την αρχιτεκτονική τριών επιπέδων, όλοι γνωρίζουν ότι είναι το επίπεδο απόδοσης (UI), το επίπεδο επιχειρηματικής λογικής (BLL) και το επίπεδο πρόσβασης δεδομένων (DAL) και υπάρχουν πολλοί τρόποι υποδιαίρεσης κάθε επιπέδου. Αλλά το πώς να γράψετε τον συγκεκριμένο κώδικα και σε ποιο επίπεδο υπολογίζονται αυτά τα αρχεία είναι ασαφές. Το παρακάτω είναι ένα απλό παράδειγμα που θα σας οδηγήσει να εξασκηθείτε σε ένα έργο αρχιτεκτονικής τριών επιπέδων, αυτό το παράδειγμα έχει μόνο μία λειτουργία, δηλαδή την απλή διαχείριση των χρηστών.
Αρχικά, δημιουργήστε μια κενή λύση και προσθέστε τα ακόλουθα στοιχεία και αρχεία
1. Προσθέστε ένα ASP.NET έργο εφαρμογής Web, ονομάστε το UI και δημιουργήστε ένα νέο αρχείο Web Form User.aspx (συμπεριλαμβανομένου του User.aspx.cs)
2. Προσθέστε ένα έργο ClassLibrary, ονομάστε το BLL και δημιουργήστε ένα νέο αρχείο Class UserBLL.cs
3. Προσθέστε ένα έργο ClassLibrary, ονομάστε το DAL και δημιουργήστε ένα νέο αρχείο Class UserDAL.cs. Προσθέστε μια αναφορά SQLHelper. (Αυτή είναι η κλάση πρόσβασης δεδομένων της Microsoft ή μπορείτε να γράψετε απευθείας όλο τον κωδικό πρόσβασης δεδομένων.) Συνήθως χρησιμοποιώ την κλάση DataAccessHelper που γράφω).
4. Προσθέστε ένα έργο ClassLibrary, ονομάστε το Μοντέλο και δημιουργήστε ένα νέο αρχείο τύπου Class UserModel.cs
5. Προσθέστε ένα έργο ClassLibrary, ονομάστε το IDAL και δημιουργήστε ένα νέο αρχείο διεπαφής IUserDAL.cs
6. Προσθέστε ένα έργο ClassLibrary και ονομάστε το ClassFactory
Πιστεύω ότι έχετε δει ότι αυτό δεν διαφέρει από το παράδειγμα του Petshop και είναι πιο απλό, γιατί μαθαίνω επίσης την αρχιτεκτονική τριών επιπέδων μέσω του Petshop. Ωστόσο, ορισμένοι φίλοι μπορεί να είναι ασαφείς σχετικά με το επίπεδο αυτών των έργων και τη σχέση μεταξύ τους, εδώ είναι μια εξήγηση για αυτά ένα προς ένα:
1. User.aspx και User.aspx.cs
Και τα δύο έγγραφα (και τα στοιχεία στα οποία ανήκει το αρχείο, καθώς και παρακάτω, δεν θα επαναληφθούν) αποτελούν μέρος του επιπέδου παρουσίασης. User.aspx είναι πιο κατανοητό επειδή είναι μια σελίδα εμφάνισης. User.aspx.cs μερικοί άνθρωποι πιστεύουν ότι δεν πρέπει να υπολογίζεται, αλλά πρέπει να περιλαμβάνεται στο επίπεδο επιχειρηματικής λογικής. Εάν δεν κάνετε layering, τότε δεν υπάρχει πρόβλημα να User.aspx.cs αφήσετε να χειριστείτε την επιχειρηματική λογική και ακόμη και να χειριστείτε τη βάση δεδομένων, αλλά αν κάνετε layering, αυτό δεν πρέπει να γίνει. Σε μια ιεραρχική δομή, User.aspx.cs θα πρέπει να ασχολείται μόνο με περιεχόμενο που σχετίζεται με την προβολή και τίποτα άλλο δεν θα πρέπει να καλύπτεται.
Για παράδειγμα, εάν εφαρμόσουμε τη λειτουργία εμφάνισης χρηστών με τη μορφή λίστας, τότε η εργασία εξαγωγής πληροφοριών γίνεται από την BLL και αφού η διεπαφή χρήστη (σε αυτήν την περίπτωση, είναι User.aspx.cs) καλέσει το BLL για να λάβει UserInfo, δεσμεύεται στον έλεγχο δεδομένων του User.aspx μέσω κώδικα για να πραγματοποιήσει την εμφάνιση της λίστας. Σε αυτή τη διαδικασία User.aspx.cs δεν παίζει ρόλο στο UI, χρησιμοποιείται μόνο για τη μετάδοση δεδομένων και επειδή το μεγαλύτερο μέρος της πραγματικής κωδικοποίησης υλοποιείται με αυτόν τον τρόπο, μερικοί άνθρωποι πιστεύουν ότι το User.aspx.cs δεν πρέπει να υπολογίζεται ως UI, αλλά θα πρέπει να συγχωνευθεί στο BLL για λογική επεξεργασία. Κοιτάζοντας περαιτέρω, προτάθηκε μια νέα απαίτηση για την προσθήκη ενός εικονιδίου μπροστά από κάθε χρήστη για να αντιπροσωπεύει ζωντανά το φύλο του χρήστη και για όσους είναι κάτω των 18 ετών, αντιπροσωπευόταν από ένα εικονίδιο παιδιού. Η υλοποίηση αυτής της απαίτησης είναι η σειρά του User.aspx.cs, και σε αυτή την περίπτωση User.aspx.cs έχει πραγματική χρήση.
2, NewBLL.cs
Προσθέστε τις ακόλουθες μεθόδους:
public IList GetUsers(): Επιστρέφει μια λίστα με όλες τις πληροφορίες χρήστη
public UserInfo GetUser(int UserId): Επιστρέφει τα στοιχεία του καθορισμένου χρήστη
public bool AddUser(UserInfo User): Προστέθηκαν πληροφορίες χρήστη
public bool ChangeUser(UserInfo User): Ενημερώνει τις πληροφορίες χρήστη
public void RemoveUser(int UserId): Καταργεί τις πληροφορίες χρήστη
Αυτό το αρχείο ανήκει στο επίπεδο επιχειρηματικής λογικής και είναι αφιερωμένο στο χειρισμό λειτουργιών που σχετίζονται με την επιχειρηματική λογική. Πολλοί άνθρωποι μπορεί να πιστεύουν ότι η μόνη χρήση αυτού του επιπέδου είναι η προώθηση των δεδομένων από το επίπεδο απόδοσης στο επίπεδο δεδομένων. Υπάρχουν πράγματι πολλές τέτοιες περιπτώσεις, αλλά αυτό μπορεί να σημαίνει μόνο ότι το έργο είναι σχετικά απλό ή ότι η σχέση μεταξύ του ίδιου του έργου και της επιχείρησης δεν είναι στενά ενσωματωμένη (όπως το τρέχον δημοφιλές MIS), επομένως το επιχειρηματικό επίπεδο δεν έχει καμία σχέση και παίζει μόνο ρόλο προώθησης. Αλλά αυτό δεν σημαίνει ότι το επιχειρηματικό επίπεδο είναι περιττό, καθώς το έργο αυξάνεται ή υπάρχουν περισσότερες επιχειρηματικές σχέσεις, το επιχειρηματικό επίπεδο θα αντικατοπτρίζει τον ρόλο του.
Το πιο πιθανό σφάλμα εδώ είναι να αντιστοιχίσετε τον κώδικα λειτουργίας δεδομένων στο επίπεδο επιχειρηματικής λογικής και στη βάση δεδομένων ως επίπεδο πρόσβασης δεδομένων.
Για παράδειγμα, ορισμένοι φίλοι πιστεύουν ότι το επίπεδο BLL δεν έχει νόημα, αλλά απλώς ανεβάζουν τα δεδομένα DAL και τα προωθούν στο UI χωρίς καμία επεξεργασία. Ρίξτε μια ματιά σε αυτό το παράδειγμα
Στρώση BLL
Το SelectUser(UserInfo userInfo) λαμβάνει τα στοιχεία χρήστη με βάση το όνομα χρήστη ή το email που εισέρχεται.
IsExist(UserInfo userInfo) καθορίζει εάν υπάρχει το καθορισμένο όνομα χρήστη ή email.
Στη συνέχεια, το DAL παρέχει επίσης την αντίστοιχη μέθοδο για την κλήση BLL
SelectUser(UserInfo userInfo)
IsExist(Πληροφορίες χρήστη)
Με αυτόν τον τρόπο, η BLL παίζει μόνο ρόλο μετάδοσης.
Αλλά αν το κάνετε:
Το BLL. IsExist(Πληροφορίες χρήστη)
{
Χρήστης UerInfo = DAL. SelectUser(Χρήστης);
επιστροφή (userInfo.Id != null);
}
Τότε το DAL δεν χρειάζεται να εφαρμόσει τη μέθοδο IsExist() και υπάρχει λογικός κώδικας επεξεργασίας στο BLL.
3, UserModel.cs
Οντότητα, αυτό το πράγμα, μπορεί να νομίζετε ότι δεν είναι εύκολο να στρωματοποιηθεί. Συμπεριλαμβανομένου και εμένα, το κατάλαβα ως εξής: UI?àModel?àBLL?àModel?àDAL, οπότε πιστεύεται ότι το Μοντέλο λειτουργεί ως γέφυρα για τη μετάδοση δεδομένων μεταξύ των επιπέδων. Αλλά εδώ, δεν σκεφτόμαστε τα πράγματα απλά, αλλά την πολυπλοκότητα.
Τι είναι το μοντέλο; Δεν είναι τίποτα! Είναι απαραίτητο σε αρχιτεκτονική τριών επιπέδων. Είναι στην πραγματικότητα το πιο βασικό πράγμα στον αντικειμενοστραφή προγραμματισμό: οι. Ένας πίνακας είναι μια τάξη, μια είδηση είναι επίσης μια τάξη, το int, το string, το doublie, κ.λπ. είναι επίσης, είναι απλώς μια τάξη.
Με αυτόν τον τρόπο, η θέση του μοντέλου στην αρχιτεκτονική τριών επιπέδων είναι ίδια με την κατάσταση μεταβλητών όπως int και string και δεν έχει άλλο σκοπό, χρησιμοποιείται μόνο για αποθήκευση δεδομένων, αλλά αποθηκεύει πολύπλοκα δεδομένα. Επομένως, εάν τα αντικείμενα στο έργο σας είναι πολύ απλά, τότε μπορείτε να περάσετε απευθείας πολλές παραμέτρους χωρίς μοντέλο για να δημιουργήσετε μια αρχιτεκτονική τριών επιπέδων.
Γιατί λοιπόν χρειάζεστε ένα μοντέλο και ποια είναι τα οφέλη του; Το παρακάτω είναι αυτό που έρχεται στο μυαλό όταν σκέφτεστε μια ερώτηση, που εισάγεται εδώ:
Μπορεί το μοντέλο να παίξει μεγαλύτερο ρόλο στο πέρασμα των παραμέτρων σε κάθε επίπεδο;
Όταν περνάτε παραμέτρους μεταξύ επιπέδων, μπορείτε να κάνετε τα εξής:
AddUser(userId;userName;userPassword,...,)
Μπορεί επίσης να είναι έτσι:
AddUser(userInfo)
Ποια από αυτές τις δύο μεθόδους είναι καλύτερη; Με μια ματιά, πρέπει να είναι το δεύτερο πολύ καλύτερο.
Πότε να περάσετε παραμέτρους μεταξύ επιπέδων με κανονικούς τύπους μεταβλητών (int, string, guid, double) και τι να περάσετε με το Model; Οι ακόλουθες μέθοδοι:
SelectUser(int UserId)
SelectUserByName(όνομα χρήστη συμβολοσειράς)
SelectUserByName(όνομα χρήστη συμβολοσειράς, κωδικός πρόσβασης συμβολοσειράς)
SelectUserByEmail(συμβολοσειρά email)
SelectUserByEmail(email συμβολοσειράς, κωδικός πρόσβασης συμβολοσειράς)
Μπορεί να συνοψιστεί ως εξής:
SelectUser(userId)
SelectUser(χρήστης)
Εδώ χρησιμοποιούμε το αντικείμενο μοντέλου χρήστη για να συμπεριλάβουμε τέσσερις τρόπους συνδυασμού ονόματος χρήστη, κωδικού πρόσβασης και email. Το UserId μπορεί επίσης να συγχωνευθεί στο user, αλλά άλλα BLL στο έργο υλοποιούν διεπαφές με παραμέτρους id, επομένως αυτό το στοιχείο διατηρείται επίσης.
Το userInfo έχει περάσει, οπότε πώς να το αντιμετωπίσετε, αυτό πρέπει να είναι με τη σειρά σειράς, υπάρχει ένας συγκεκριμένος κωδικός για να αποφασίσετε.
Εδώ επεξεργάζεται με αυτή τη σειρά
Πρώτα, δείτε αν έχετε όνομα χρήστη και κωδικό πρόσβασης, μετά δείτε αν έχετε email και κωδικό πρόσβασης, μετά δείτε αν έχετε όνομα χρήστη και, μετά δείτε αν έχετε email. Υποβάλλεται σε διαδοχική επεξεργασία.
Με αυτόν τον τρόπο, εάν προστεθεί ένα νέο περιεχόμενο στο μέλλον, η κάρτα μέλους (αριθμός), δεν χρειάζεται να αλλάξετε τη διεπαφή, απλώς προσθέστε υποστήριξη για τον αριθμό στον κώδικα DAL και, στη συνέχεια, προσθέστε την απόδοση και την επεξεργασία του περιεχομένου της κάρτας μέλους στο προσκήνιο.
4, UserDAL.cs
public IList SelectUsers(): Επιστρέφει μια λίστα με όλες τις πληροφορίες χρήστη
public UserInfo SelectUser(int UserId): Επιστρέφει τις αξιόπιστες πληροφορίες του καθορισμένου χρήστη
public bool InsertUser(UserInfo User): Προστέθηκαν πληροφορίες χρήστη
public bool UpdateUser(UserInfo User): Ενημερώνει τις πληροφορίες χρήστη
public void DeleteUser(int UserId): Καταργεί τις πληροφορίες χρήστη
Αυτό που πολλοί άνθρωποι δεν μπορούν να καταλάβουν περισσότερο είναι το επίπεδο πρόσβασης δεδομένων, ποιο μέρος θεωρείται το επίπεδο πρόσβασης δεδομένων; Μερικοί άνθρωποι πιστεύουν ότι η βάση δεδομένων είναι το επίπεδο πρόσβασης δεδομένων, το οποίο δεν είναι σαφές σχετικά με τον ορισμό, το DAL είναι το επίπεδο πρόσβασης δεδομένων και όχι το επίπεδο αποθήκευσης δεδομένων, επομένως η βάση δεδομένων δεν μπορεί να είναι αυτό το επίπεδο. Ο ρόλος του SQLHelper είναι να μειώσει την επαναλαμβανόμενη κωδικοποίηση και να βελτιώσει την αποτελεσματικότητα της κωδικοποίησης, οπότε αν έχω συνηθίσει να ενδιαφέρομαι για την αποτελεσματικότητα ή να χρησιμοποιώ μια πηγή δεδομένων εκτός βάσης δεδομένων, μπορώ να απορρίψω το SQLHelper, ένα μέρος που μπορεί να απορριφθεί κατά βούληση, πώς μπορεί να γίνει ένα επίπεδο της αρχιτεκτονικής τριών επιπέδων.
Μπορεί να οριστεί ως εξής: ο κώδικας που σχετίζεται με τις λειτουργίες πηγής δεδομένων θα πρέπει να τοποθετηθεί στο επίπεδο πρόσβασης δεδομένων, το οποίο ανήκει στο επίπεδο πρόσβασης δεδομένων
5, IUserDAL
Διεπαφή επιπέδου πρόσβασης δεδομένων, αυτό είναι ένα άλλο περιττό πράγμα, επειδή το Petshop το φέρνει και το εργοστάσιο ClassFactory μαζί του, επομένως ορισμένα έργα κάνουν αυτά τα δύο πράγματα ανεξάρτητα από το αν χρειάζεται να υποστηρίζουν πολλαπλές πηγές δεδομένων ή όχι, και μερικά ακόμη δεν κατασκευάζουν το ClassFactory αλλά κατασκευάζουν μόνο IDAL, και μετά "IUserDAL iUserDal = νέο UserDAL(); Δεν ξέρω ποιο είναι το νόημα. Αυτό είναι εντελώς τίγρης και όχι αντι-σκύλος.
Πολλοί άνθρωποι έχουν μια λανθασμένη αντίληψη εδώ, δηλαδή ότι υπάρχει μια τέτοια σχέση: BLL?àIDAL?àDAL, νομίζοντας ότι το IDAL λειτουργεί ως γέφυρα μεταξύ BLL και DAL, και το BLL καλεί το DAL μέσω του IDAL. Αλλά η πραγματικότητα είναι ότι ακόμα κι αν το κωδικοποιήσετε με αυτόν τον τρόπο: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Όταν εκτελούμε το "iUserDal.SelectUsers()", στην πραγματικότητα είναι το instance του UserDAL που εκτελείται, όχι το instance του IUserDAL, οπότε η θέση του IDAL στο τρίτο επίπεδο σχετίζεται με το επίπεδο του DAL.
Μέσα από την παραπάνω εισαγωγή, εξηγείται βασικά η ιεραρχία της αρχιτεκτονικής τριών επιπέδων. Στην πραγματικότητα, έχω έναν τρόπο να κρίνω εάν η αρχιτεκτονική τριών επιπέδων είναι τυπική, δηλαδή, η πλήρης αντικατάσταση οποιουδήποτε από τα τρία επίπεδα δεν θα επηρεάσει τα άλλα δύο επίπεδα και μια τέτοια δομή πληροί βασικά το πρότυπο τριών επιπέδων (αν και είναι πιο δύσκολο ^_^ να εφαρμοστεί). Για παράδειγμα, αν αλλάξετε το έργο από B/S σε C/S (ή αντίστροφα), τότε το BLL και το DAL δεν χρειάζεται να αλλάξουν εκτός από το UI. Ή αλλάξτε το SQLServer σε Oracle, απλώς αντικαταστήστε το SQLServerDAL σε OracleDAL, δεν απαιτούνται άλλες λειτουργίες κ.λπ. Αρχικά ήθελα να προσθέσω κάποιο συγκεκριμένο κώδικα στο άρθρο, αλλά δεν νομίζω ότι είναι απαραίτητο, αν το θεωρείτε απαραίτητο, θα τον προσθέσω.
Περίληψη: Μην νομίζετε ότι ένα επίπεδο είναι περιττό μόνο και μόνο επειδή είναι άχρηστο για εσάς ή είναι ιδιαίτερα απλό να το εφαρμόσετε ή να το εγκαταλείψετε ή να το χρησιμοποιήσετε για άλλους σκοπούς. Εφόσον εκτελούνται τα επίπεδα, ανεξάρτητα από το πόσα επίπεδα υπάρχουν, κάθε στρώμα πρέπει να έχει σαφή υλοποίηση σκοπού και λειτουργίας και δεν πρέπει να επηρεάζεται από την πραγματική διαδικασία, με αποτέλεσμα ο ίδιος τύπος αρχείου να βρίσκεται σε διαφορετικά επίπεδα. Μην αφήνετε το ίδιο επίπεδο να υλοποιεί διαφορετικές λειτουργίες. |
Δημοσιεύτηκε στις 7/5/2015 10:53:35 π.μ.
|
|
|
