architettura n-strati - BLL, DAL e interfacce. Qual è la cosa migliore pratica?

Question

Ho una domanda per quanto riguarda l'architettura n-layer. Ho pensato a lungo prima di fare questa domanda in quanto vi sono un sacco di domande simili già qui ... però, dopo letteralmente un giorno e mezzo a guardarla e la lettura di queste altre risposte sono ancora incerti. La varietà di terminologia e diversi approcci apparentemente simili mi ha confuso.

Se avessi un BLL e DAL in librerie di classi diverse, in un modo per comunicare tra il BLL e DAL potrebbe essere quella di utilizzare un'interfaccia, come una sorta di DTO definita in un altro DLL separato che è stato riferito da entrambi BLL e DAL . I miei entità del modello di dominio nel BLL avrebbero implementare questa interfaccia e così avrebbe alcun oggetto ORM generato nel DAL. Per salvare i miei soggetti imprenditoriali ho potuto poi passarli al DAL che li avrebbe accettato bene perché implementano l'interfaccia condivisa. Potrei anche passare gli oggetti di nuovo alla BLL che implementano questa interfaccia. Questo sembra ragionevole sia come BLL e DAL poi solo bisogno di essere a conoscenza della interfaccia di base, non ogni altri concreta attuazione.

La mia domanda è che cosa è ciò che è il metodo migliore per creare l'oggetto dall'altra parte? Per esempio, se ho avuto un oggetto Person nel BLL che ha implementato IPerson, e un PersonDataObject o qualsiasi altra cosa nella DLL che implementa anche IPerson, passo persona ad un metodo nel DAL che prende un parametro di IPerson, poi nel DAL I' d dover ricostruire una PersonDataObject a persistere. E 'questo anche il metodo migliore?

Mi dispiace, probabilmente non hanno spiegato fin troppo bene come sto abbastanza confuso. Una best practice per i manichini risposta sarebbe molto apprezzato.

Answer 1

In linea generale, gli oggetti nel BLL consumerà le interfacce - non la loro attuazione:

  

Per esempio, se ho avuto un oggetto Person   nel BLL che ha implementato IPerson,   e un PersonDataObject o qualsiasi altra cosa in   la DLL che implementa anche IPerson

Facendo una "persona" come esempio: pensare alle diverse operazioni di dati associati con una persona (Ottenere tutti i dati per una sola persona, una raccolta di dati poco profonde per molte persone, le operazioni CRUD, ricerca, ecc) - quindi interfacce di progettazione lungo raggruppamenti logici (vedere il interfaccia Segeragtion Principio ).

Le interfacce potrebbe rappresentare operazioni da una prospettiva centrata BL -. O un "servizio" una basata

In ogni caso, per rispondere alla tua domanda specifica ...

I definire il mio equivalente di DTO in un Comune di montaggio, e l'interfaccia dati in una struttura separata, come pure - così ho 4 gruppi: BL, Data Definition accesso Inteface, l'implementazione dell'interfaccia e comuni; tutti i complessi riferimento quello comune.

sto lavorando in C # .Net, definisco le DTOs come le strutture (ma si potrebbe utilizzare le classi); e tutte le proprietà di questi sono di sola lettura - si alimenta i dati in loro nel costruttore -. questo modo i di DTO sono effectly 'muti' buste di informazioni

Answer 2

Seguendo l'architettura a più livelli, è molto comune per condividere gli oggetti dati fra BL e DAL. A volte, lo stesso oggetto dati può essere utilizzato nello strato UI pure.

Di solito ho un modello di dati (o oggetti dati o modello di dominio, tutto ciò è il nome) di montaggio che ospita tutti i modelli di oggetti come interfacce. Prendendo il tuo esempio la gente, voglio creare un'interfaccia IPeople nel modello dell'assieme. DAL restituirà un'istanza di IPeople BL. BL consumerà questo caso e se necessario passare questo allo strato di interfaccia dopo l'applicazione logica aziendale.

Answer 3

Google per il dominio guidato la progettazione e il modello repository. Si soumnds come si sono diretti in quella direzione con la propria architettura e, a seconda che lo scenario giustifichi vorrei usare questo approccio in codice più complicato.