Prefazione
Speriamo che sia ovvio, ma ... negli spazi dei nomi suggeriti qui sotto, sostituirai MyCompany e MyProject con i nomi effettivi della tua azienda e del tuo progetto.
DTOs
Raccomando di utilizzare le stesse classi DTO su tutti i livelli. Meno punti di manutenzione in questo modo. Di solito li metto sotto uno spazio dei nomi MyCompany.MyProject.Models , nel loro stesso progetto VS con lo stesso nome. E di solito li chiamo semplicemente dopo l'entità del mondo reale che rappresentano. (Idealmente, le tabelle del database usano anche gli stessi nomi, ma a volte ha senso impostare lo schema in modo leggermente diverso lì.)
Esempi: Person , Address , Product
Dipendenze: Nessuna (diversa dalle normali librerie .NET o helper)
DAL
La mia preferenza personale qui è quella di utilizzare un set di classi DAL one-for-one che corrisponde alle classi DTO, ma in uno spazio dei nomi / progetto MyCompany.MyProject.DataAccess . I nomi delle classi qui terminano con un suffisso Engine per evitare conflitti. (Se non ti piace quel termine, allora un suffisso DataAccess funzionerebbe bene. Basta essere coerenti con qualsiasi cosa tu scelga.) Ogni classe fornisce semplici opzioni CRUD che colpiscono il database, usando le classi DTO per la maggior parte dei parametri di input e ritorno tipi (all'interno di un generico List quando ce ne sono più di uno, ad es. il ritorno da un metodo Find() ).
Esempi: PersonEngine , AddressEngine , ProductEngine
Dipendenze: MyCompany.MyProject.Models
BAL / BLL
Anche qui mappatura one-for-one, ma in uno spazio dei nomi / progetto MyCompany.MyProject.Logic e con le classi che ottengono un suffisso Logic . Questo dovrebbe essere il livello solo che chiama il DAL! Le classi qui sono spesso solo un semplice pass-through al DAL, ma se & quando è necessario implementare le regole aziendali, questo è il posto giusto.
Esempi: PersonLogic , AddressLogic , ProductLogic
Dipendenze: MyCompany.MyProject.Models , MyCompany.MyProject.DataAccess
API
Se esiste un livello API dei servizi Web, utilizzo lo stesso approccio one-for-one, ma in uno spazio dei nomi / progetto MyCompany.MyProject.WebApi , con Services come suffisso della classe. (A meno che tu non stia utilizzando l'API Web ASP.NET, nel qual caso dovresti utilizzare il suffisso Controller ).
Esempi: PersonServices , AddressServices , ProductServices
Dipendenze: MyCompany.MyProject.Models , MyCompany.MyProject.Logic (mai ignorare ciò chiamando direttamente il DAL!)
Un'osservazione sulla logica aziendale
Sembra che sia sempre più comune per le persone escludere BAL / BLL, e invece implementare la logica di business in uno o più degli altri livelli, ovunque abbia più senso. In tal caso, sii assolutamente certo che (1) tutto il codice dell'applicazione passa attraverso il / i livello / i con la logica aziendale e (2) è ovvio e / o ben documentato dove è stata implementata ogni particolare regola aziendale. In caso di dubbio, non provarlo a casa.
Una nota finale sull'architettura a livello aziendale
Se ti trovi in una grande azienda o in un'altra situazione in cui le stesse tabelle di database vengono condivise tra più applicazioni, ti consigliamo di lasciare la porzione MyProject dei namespace / progetti sopra indicati. In questo modo questi livelli possono essere condivisi da più applicazioni front-end (e anche da utilità dietro le quinte come Windows Services). Tuttavia, esegui questa operazione solo se disponi di una strong comunicazione tra team e di test di regressione automatici completi. In caso contrario, le modifiche di un team a un componente principale condiviso potrebbero compromettere l'applicazione di un'altra squadra.