Necessario feedback sull'architettura di livello n

Question

Ho iniziato il mio sito Web, come StackOverflow, con un piccolo debito tecnico che sto cercando di ripagare. Essendo uno sviluppatore del contratto, sono stato in molti posti e vedo molti metodi diversi per raggiungere questo risultato, ma il modo in cui sto andando è ..

Presentazione (web)

Livello aziendale (classi di entità vecchio stile e livello BL)

Livello dati (classi DA in SQL Server tramite Stored Proc)

La mia domanda riguarda principalmente il livello aziendale. In questo momento ho uno spazio dei nomi Entity e uno spazio dei nomi BusinessLogic.

Il BL ha un riferimento al DA e all'entità. L'Entità ha un riferimento al DA (Il DA è "inconsapevole" del BL o Entity)

Voglio davvero che tutta la mia sfocatura di trasformare i Dati in Entità avvenga all'interno del BL, quindi la Business Logic. Tuttavia, desidero che l'Entità sia in grado di accedere al BL, se necessario, e quindi rimuovere il riferimento dell'Entità al DL.

...

È " sbagliato " avere gli oggetti BL ed Entity nello stesso spazio dei nomi in modo che possano lavorare insieme?

In sostanza, sto provando ad avere un oggetto entità come Employee (esempio classico, eh?) e che il Employee abbia un

public Hashtable[] SubordinateEmployees

proprietà che restituisce un Hashtable di altri oggetti Employee che riportano a questo dipendente. Ma non voglio caricarlo fino a quando non è necessario. Quindi per la maggior parte dei dipendenti la proprietà non avrebbe mai avuto accesso, ma quando lo fa, si carica automaticamente con una chiamata al BL, che chiama il DA.

La domanda ha senso?

In tal caso, la mia soluzione?

Grazie mille in anticipo!

Answer 1

Il solito modo di affrontare il tipo di situazione rappresentata dal tuo esempio è con le facciate. Invece di provare a ottenere i dipendenti subordinati dall'oggetto Employee, per ottenerlo usi una chiamata alla logica aziendale.

hashtable = BL.GetSubordinateEmployees(supervisor);

In questo modo hai un unico punto di accesso ai subordinati e c'è solo una cosa (il BL) accedere al livello dati e creare Entità.

Answer 2

Fammi vedere se posso mostrarti un modo migliore di pensarci

hai accesso ai tuoi dati (sql server, mysql, file xml piatti, ecc.) tutto questo dovrebbe essere sottratto a nient'altro nella tua applicazione dovrebbe interessarti o sapere come stai ottenendo i tuoi dati, solo che li dosano, se qualsiasi altra cosa sa come stai ottenendo i tuoi dati hai una violazione del livello. se il DAL dosa qualcos'altro, quindi ottieni i dati hai una violazione del livello. Successivamente implementate un'interfaccia di accesso ai dati simile a IDAL utilizzata dal vostro livello aziendale, questo è molto importante per rendere testabile il codice costringendovi a separare i livelli.

Le tue entità di dati possono essere posizionate nello spazio dei nomi DAL o assegnarle proprio, dandole la propria separazione delle forze. Le entità di dati sono oggetti stupidi e dovrebbero contenere pochissima o nessuna logica e sono consapevoli solo di se stessi e dei dati che possiedono, NON CONTENGONO LOGICA DI AFFARI !, ACCESSO A DATI LOCICI O LOGICA UI. se lo fanno hai una violazione del livello. L'unica funzione di un'entità dati è conservare i dati e passare da un livello a quello successivo.

Il livello Biz implementa un'interfaccia di accesso ai dati come l'IDAL di cui abbiamo parlato prima che tu possa creare un'istanza con una fabbrica, un contenitore IOC o tutti gli altri errori di un tipo concreto, ma aggiungi una proprietà setter in modo che possa essere modificata per il test. Il livello Biz gestisce solo la logica aziendale, non sa né importa da dove provengono i dati o dove sta andando, si preoccupa solo di manipolare i dati per conformarsi alle regole aziendali, questo include la convalida della data, il filtro (parte di questo è dicendo al DAL di quali dati ha bisogno, lascia che il DAL capisca come ottenerlo). Fondamentalmente il BIZ gestisce tutta la logica che non è correlata all'interfaccia utente o al recupero dei dati. Proprio come DAL, Biz dovrebbe implementare un'interfaccia per lo stesso motivo.

Il livello UI Accede al livello Biz nello stesso modo in cui il livello Biz accede al DAL per lo stesso motivo. Tutto il livello dell'interfaccia utente si preoccupa di visualizzare i dati e ottenere dati dall'utente. Il livello IU non dovrebbe conoscere nulla delle regole aziendali, con la possibile eccezione della convalida dei dati richiesta per popolare le entità dei dati.

Il vantaggio di questa architettura è che forza la separazione delle preoccupazioni rendendo più facile il test, più flessibile e più facile da mantenere. Oggi stai costruendo un sito web ma domani vuoi consentire ad altri di integrare vi un servizio web, tutto quello che devi fare è creare un servizio web che implementa l'interfaccia IBIZ e il tuo lavoro, quando devi correggere un bug nel BIZ livello, è già stato risolto sia nel tuo sito web che nel tuo servizio web.

Portando questo al livello successivo, supponiamo che tu stia facendo un sacco di scricchiolii di numeri pesanti e che tu abbia bisogno di server più potenti per gestirlo, quindi tutto ciò che devi fare è implementare un'interfaccia IDal e IBIZ che siano davvero avvolgenti per WCF che gestisce la comunicazione tra i server, ora l'applicazione è distribuita tra più server e non è stato necessario modificare il codice per farlo.