N-Tier vale quando si sviluppa un'applicazione ASP.NET?

1

Lasciatemi dire che "vale" non intendo "rimuovere DI e interfacce" e così.

Ciò che intendo è posizionare il codice in librerie di classi separate. Come fatto nella Onion architecture - che mi piace molto.

Il problema è che il progetto ASP.NET è il bootstrapper quando in realtà dovrebbe semplicemente fare roba di presentazione web. Diventa ancora peggio quando si utilizza Identity perché la classe ApplicationUser è strettamente accoppiata con Entity Framework. Perché ora il tuo core dipende da EF. Quale non è l'N-Tier.

Quindi la mia domanda è. Separare il codice in librerie di classi diverse vale la pena quando si fa ASP.NET?

    
posta Snæbjørn 27.06.2015 - 13:37
fonte

1 risposta

4

Separare il codice nelle librerie di classi (ad esempio, gli assembly separati) può migliorare la progettazione perché è possibile gestire le dipendenze in modo chiaro, ad es. puoi assicurarti che il frontend abbia un riferimento al livello di accesso ai dati ma non viceversa. .Net consente di evitare le dipendenze circolari tra classi, ma non tra assiemi e dipendenze circolari tra livelli. Non c'è un grosso costo per la creazione di diversi progetti in VS, quindi direi che ne vale sicuramente la pena.

Ma questa non è un'architettura n-tier. I livelli in n-tier sono fisicamente separati (su server diversi) e comunicano attraverso la rete. Naturalmente questo introduce una complessità aggiuntiva poiché ogni livello ha bisogno di un'interfaccia di servizio e di una rete, ecc., Quindi vale la pena se si hanno requisiti specifici come la possibilità per i frontend indipendenti indipendenti di accedere allo stesso livello di logica aziendale.

    
risposta data 27.06.2015 - 14:33
fonte

Leggi altre domande sui tag