BLL è il livello di Business Logic
DAL è il Livello di Accesso ai Dati
Architettura a tre livelli di ASP.NET (DAL, BLL, UI)
La grafica rappresenta una struttura a tre livelli. Il web è il livello USL
web –> bll –> dal
| | |
| V |
+–> modello <—+
1. Architettura a tre livelli
1. Livello di presentazione (USL): rappresenta principalmente il metodo WEB, ma può anche essere espresso come modalità WINFORM. Se il livello logico è piuttosto robusto e ben consolidato, funzionerà perfettamente indipendentemente da come venga definito e modificato il livello delle prestazioni.
2. Livello di logica aziendale (BLL): principalmente per problemi specifici, può essere inteso anche come il funzionamento del livello dati e l'elaborazione logica del business dei dati. Se il livello dati è costituito dai mattoni di costruzione, allora il livello logico è il blocco di costruzione.
3. Livello di accesso ai dati (DAL): È principalmente il livello operativo dei dati originali (sotto forma di database, file di testo o altro tipo di memorizzazione dei dati), piuttosto che i dati originali, cioè il funzionamento dei dati, non il database, specificamente il livello di logica aziendale o il livello di presentazione
Fornitura di servizi dati.
2. Distinzione specifica
1. Livello di presentazione: accetta principalmente la richiesta dell'utente e restituisce dati, fornendo al client l'accesso all'applicazione.
2. Livello di logica aziendale: principalmente responsabile del funzionamento del livello dati, cioè la combinazione di alcune operazioni del livello dati.
3. Livello di accesso ai dati: dipende principalmente dal fatto che il tuo livello dati contenga elaborazione logica; infatti, le sue funzioni completano principalmente varie operazioni sul file dati e non devono preoccuparsi di altre operazioni.
3. Sommario
La struttura a tre livelli è un approccio gerarchico rigoroso, cioè il livello di accesso ai dati (DAL) può essere accessibile solo dal livello di logica aziendale (BLL), mentre il livello logica aziendale può essere raggiunto solo dal livello di presentazione (USL). Alcune strutture a tre livelli aggiungono anche altri livelli come Factory e Model, che in realtà sono un'estensione e un'applicazione basate su questi tre livelli.
Un semplice programma a tre livelli generalmente include diversi progetti del Modello Web DAL BLL, e i loro riferimenti reciproci sono i seguenti
1) RIFERIMENTI WEB BLL, Modello
2) BLL fa riferimento a DAL, modello
3) Riferimenti DAL Modello
4) Il modello non ha citazioni
Quando si parla dell'architettura a tre livelli, tutti sanno che si tratta del livello delle prestazioni (UI), del livello di logica aziendale (BLL) e del livello di accesso ai dati (DAL), e ci sono molti modi per suddividere ogni livello. Ma come scrivere il codice specifico e in quale livello vengono conteggiati quei file è vago. Di seguito è un esempio semplice per portarti a praticare un progetto di architettura a tre livelli; questo esempio ha una sola funzione, cioè la semplice gestione degli utenti.
Per prima cosa, crea una soluzione vuota e aggiungi i seguenti elementi e file
1. Aggiungere un progetto di ASP.NET Web Application (Applicazioni Web), chiamarlo UI e creare un nuovo file Web Form User.aspx (inclusi User.aspx.cs)
2. Aggiungi un progetto ClassLibrary, chiamalo BLL e crea un nuovo file Class UserBLL.cs
3. Aggiungi un progetto ClassLibrary, chiamalo DAL e crea un nuovo file Class UserDAL.cs. Aggiungi un riferimento SQLHelper. (Questa è la classe di accesso ai dati di Microsoft, oppure puoi scrivere tutto il codice di accesso direttamente ai dati.) Di solito uso la classe DataAccessHelper che scrivo).
4. Aggiungi un progetto ClassLibrary, chiamalo Model e crea un nuovo file di tipo Class UserModel.cs
5. Aggiungi un progetto ClassLibrary, chiamalo IDAL e crea un nuovo file Interface IUserDAL.cs
6. Aggiungi un progetto ClassLibrary e chiamalo ClassFactory
Credo che tu abbia visto che questo non è diverso dall'esempio di Petshop, ed è più semplice, perché imparo anche l'architettura a tre livelli tramite Petshop. Tuttavia, alcuni amici potrebbero essere vaghi riguardo al livello di questi progetti e al rapporto tra essi, ecco una spiegazione su di essi uno per uno:
1. User.aspx e User.aspx.cs
Entrambi i documenti (e gli elementi a cui appartiene il file, così come quelli sottostanti, non saranno ripetuti) fanno parte del livello di presentazione. User.aspx è più facile da capire perché è una pagina di visualizzazione. User.aspx.cs alcune persone pensano che non debba essere considerata, ma inclusa nel livello della logica aziendale. Se non fai layering, non c'è problema a lasciare che User.aspx.cs gestisca la logica di business e persino gestisca il database, ma se fai layering, non dovrebbe essere fatto. In una struttura gerarchica, User.aspx.cs dovrebbe occuparsi solo di contenuti legati alla visualizzazione, e nulla altro dovrebbe essere coperto.
Ad esempio, se implementiamo la funzione di visualizzare gli utenti sotto forma di lista, allora il lavoro di estrazione delle informazioni viene svolto da BLL, e dopo che l'interfaccia utente (in questo caso, è User.aspx.cs) chiama BLL per ottenere UserInfo, essa viene vincolata al controllo dati del User.aspx tramite codice per realizzare la visualizzazione della lista. In questo processo User.aspx.cs non ha un ruolo nell'interfaccia utente, viene usato solo per passare dati, e poiché la maggior parte del codice effettivo è implementato così, alcune persone ritengono che User.aspx.cs non debba essere conteggiato come UI, ma dovrebbe essere unito a BLL per l'elaborazione logica. Guardando oltre, è stato proposto un nuovo requisito per aggiungere un'icona davanti a ciascun utente per rappresentare vividamente il genere dell'utente, e per chi aveva meno di 18 anni, era rappresentata da un'icona di bambino. La realizzazione di questo requisito è il turno di User.aspx.cs, e in questo caso User.aspx.cs ha un reale uso.
2、NewBLL.cs
Aggiungi i seguenti metodi:
pubblico IList GetUsers(): restituisce un elenco di tutte le informazioni sugli utenti
public UserInfo GetUser(int UserId): restituisce i dettagli dell'utente specificato
public bool AddUser(UserInfo User): Informazioni utente aggiunte
public bool ChangeUser(UserInfo User): Aggiorna le informazioni utente
public void RemoveUser(int UserId): Rimuove le informazioni utente
Questo file appartiene al livello della logica aziendale ed è dedicato alla gestione delle operazioni relative alla logica aziendale. Molte persone potrebbero pensare che l'unico uso di questo livello sia inoltrare i dati dal livello delle prestazioni a quello dei dati. Ci sono infatti molti casi simili, ma questo può significare solo che il progetto è relativamente semplice, oppure che la relazione tra il progetto stesso e l'azienda non è strettamente integrata (come l'attuale popolare MIS), quindi il livello business non ha nulla a che fare e svolge solo un ruolo di inoltro. Ma questo non significa che il livello business sia sacrificabile: man mano che il progetto cresce o ci sono più relazioni commerciali, lo strato business rifletterà il suo ruolo.
L'errore più probabile qui è assegnare il codice di operazione dati al livello di logica aziendale e il database come livello di accesso ai dati.
Ad esempio, alcuni amici pensano che il livello BLL non sia significativo, ma caricano semplicemente i dati DAL e li inoltrono all'interfaccia senza alcuna elaborazione. Dai un'occhiata a questo esempio
Strato BLL
SelectUser(UserInfo userInfo) ottiene i dati utente in base al nome utente o all'email che arriva.
IsExist(UserInfo userInfo) determina se il nome utente o l'email specificati esiste.
Poi il DAL fornisce anche il metodo corrispondente per la chiamata BLL
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
In questo modo, BLL svolge solo un ruolo di trasmissione.
Ma se lo fai:
BLL. IsExist(Userinfo userinfo)
{
UerInfo utente = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Allora DAL non ha bisogno di implementare il metodo IsExist(), e in BLL c'è codice di elaborazione logica.
3、UserModel.cs
Entità, questa cosa, potresti pensare che non sia facile stratificare. Includendomi, l'ho capito così: UI?àModel?àBLL?àModel?àDAL, quindi si ritiene che il Modello agisca come un ponte per la trasmissione dei dati tra i livelli. Ma qui non pensiamo alle cose in modo semplice, ma alla complessità.
Cos'è Model? Non è niente! È dispensabile in un'architettura a tre livelli. In realtà è la cosa più basilare nella programmazione orientata agli oggetti: le classi. Una tabella è una classe, una notizia è anche una classe, int, string, doublie, ecc. sono anch'esse classi, è solo una classe.
In questo modo, la posizione del modello nell'architettura a tre livelli è la stessa dello stato di variabili come int e stringa, e non ha altro scopo, viene utilizzato solo per l'archiviazione dei dati, ma memorizza dati complessi. Pertanto, se gli oggetti nel tuo progetto sono molto semplici, puoi passare direttamente più parametri senza un modello per creare un'architettura a tre livelli.
Allora perché hai bisogno di un modello e quali sono i suoi vantaggi? Quanto segue è ciò che viene in mente quando si riflette su una domanda, inserita qui:
Il Modello può avere un ruolo più importante nel passaggio dei parametri a ogni livello?
Quando si passa parametri tra i livelli, si può fare quanto segue:
AggiungiUser(userId, UserName,userPassword,...,)
Può anche essere così:
AddUser(userInfo)
Quale di questi due metodi è migliore? A prima vista, deve essere la seconda molto meglio.
Quando passare i parametri tra i livelli con tipi normali di variabili (int, string, guid, double) e cosa passare con Model? I seguenti metodi:
SelectUser(int UserId)
SelectUserByName(stringa nome utente)
SelectUserByName(stringstringname username,string password)
SelectUserByEmail (stringa email)
SelezionaUserByEmail(stringa email, stringa password)
Può essere riassunto così:
SelectUser(userId)
SelectUser(user)
Qui usiamo l'oggetto user model per includere quattro modalità combinate: username, password ed email. UserId può anche essere unito con user, ma altri BLL nel progetto implementano interfacce con parametri id, quindi anche questo elemento viene mantenuto.
userInfo viene passato, quindi come gestirlo, deve essere in ordine di ordine, c'è un codice specifico da decidere.
Qui viene elaborato in questo ordine
Prima controlla se hai sia nome utente che password, poi se hai sia email che password, poi se hai nome utente e infine se hai email. Elaborato in sequenza.
In questo modo, se in futuro verrà aggiunto un nuovo contenuto, la tessera di appartenenza (numero), non è necessario modificare l'interfaccia, basta aggiungere il supporto per il numero nel codice DAL, e poi aggiungere le prestazioni e l'elaborazione del contenuto della tessera di appartenenza in primo piano.
4、UserDAL.cs
pubblico IList SelectUsers(): restituisce un elenco di tutte le informazioni sugli utenti
public UserInfo SelectUser(int UserId): restituisce le informazioni affidabili dell'utente specificato
public bool InsertUser(UserInfo User): Informazioni utente aggiunte
public bool UpdateUser(UserInfo User): Aggiorna le informazioni utente
public void DeleteUser(int UserId): Rimuove le informazioni utente
Quello che molte persone non riescono a capire di più è il livello di accesso ai dati, quale parte è considerata il livello di accesso ai dati? Alcune persone pensano che il database sia il livello di accesso ai dati, cosa che non è chiara sulla definizione; DAL è il livello di accesso ai dati piuttosto che quello di archiviazione, quindi il database non può essere questo livello. Il ruolo di SQLHelper è ridurre la codifica ripetitiva e migliorare l'efficienza della codifica, quindi se sono abituato a preoccuparmi dell'efficienza o a usare una fonte di dati non basata su database, posso scartare SQLHelper, una parte che può essere scartata a piacimento, come può diventare uno strato dell'architettura a tre livelli?
Può essere definito come segue: il codice relativo alle operazioni sulla sorgente dati dovrebbe essere collocato nel livello di accesso dati, che appartiene al livello di accesso ai dati
5、IUserDAL
interfaccia del livello di accesso ai dati, questa è un'altra cosa sacrificabile, perché Petshop la porta insieme a ClassFactory factory, quindi alcuni progetti fanno queste due cose indipendentemente dal fatto che debbano supportare più fonti dati o meno, e alcuni addirittura non costruiscono ClassFactory ma solo IDAL, e poi "IUserDAL iUserDal = new UserDAL(); Non so cosa significhi. Questo è completamente una tigre e non un anti-cane.
Molte persone hanno un fraintendimento qui, cioè che esista tale relazione: BLL?àIDAL?àDAL, pensando che IDAL agisca come un ponte tra BLL e DAL, e che BLL chiami DAL tramite IDAL. Ma la realtà è che anche se lo programmi così: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Quando si esegue "iUserDal.SelectUsers()", in realtà viene eseguita l'istanza UserDAL, non l'istanza IUserDAL, quindi la posizione di IDAL nel terzo livello è correlata al livello DAL.
Attraverso l'introduzione sopra, la gerarchia dell'architettura a tre livelli viene sostanzialmente spiegata. In effetti, ho un modo per giudicare se l'architettura a tre livelli è standard, cioè se sostituire completamente uno dei tre livelli non influenzerà gli altri due livelli, e se tale struttura rispetta sostanzialmente lo standard a tre livelli (anche se è più difficile ^_^ da implementare). Ad esempio, se cambi il progetto da B/S a C/S (o viceversa), allora BLL e DAL non devono essere cambiati tranne che per l'interfaccia utente; Oppure cambiare SQLServer in Oracle, sostituire semplicemente SQLServerDAL con OracleDAL, non sono richieste altre operazioni, ecc. Inizialmente volevo aggiungere un codice specifico all'articolo, ma non credo sia necessario; se lo ritenete necessario, lo aggiungerò.
Riassunto: Non pensare che un livello sia inutile solo perché è inutile per te, o perché è particolarmente semplice da implementare, o da abbandonare, o da usare per altri scopi. Finché i livelli vengono eseguiti, indipendentemente da quanti livelli ci siano, ogni livello deve avere uno scopo e una funzione chiara e non deve essere influenzato dal processo effettivo, facendo sì che lo stesso tipo di file si trovi in livelli diversi. Non lasciare che lo stesso livello implementi funzioni diverse. |
Pubblicato su 07/05/2015 10:53:35
|
|
|
