Architettura N-Layer

Secondo me, il mix di interfacce per servizi e repository in un progetto non è una buona idea. In questo modo verranno esposte interfacce non necessarie a progetti che non ne hanno bisogno (ad esempio, DAL non ha bisogno di conoscere le interfacce di servizio, l'interfaccia utente non ha bisogno di conoscere le interfacce degli archivi in strati rigorosi)

Di seguito è riportata una struttura comune che uso frequentemente nelle mie applicazioni a più livelli. È un riferimento dai libri (i modelli di progettazione ASP.NET Professional sono più specifici) e alcuni articoli online con la mia modifica

Questa struttura ha 4 livelli che si trovano comunemente in DDD: UI - > Servizi applicativi - > Dominio (Entità + Servizi di dominio) + Repository. La parte centrale dell'applicazione è il progetto principale in cui contiene tutte le logiche di business, le entità aziendali e le interfacce per i repository (da utilizzare per i servizi applicativi). La logica di accesso ai dati / ORM è incapsulata nel progetto di repository. L'interfaccia utente dipende solo dalle interfacce dei servizi applicativi. Qui presumo che tu usi il contenitore IoC per l'integrazione delle dipendenze con il progetto dell'interfaccia utente come root di composizione.

Oltre ai progetti elencati qui, ovviamente puoi avere altri progetti come:

• Infrastruttura: infrastruttura correlata, ad es. la registrazione
• DependencyResolution: sposta qui il codice di configurazione del contenitore IoC se non vuoi inserire il progetto dell'interfaccia utente

L'implementazione sembra andare bene come in un'architettura tradizionale N-Layer.

• Nella stratificazione rigorosa il livello dell'interfaccia utente chiamerà sempre BLL, che chiamerà quindi DAL, l'interfaccia utente non potrà chiamare direttamente DAL.
• Nel caso in cui non ci sia molta logica aziendale puoi chiamare direttamente DAL dall'interfaccia utente ed evitare completamente BLL.
• Puoi anche avere un mix, business logic in BLL, UI che chiama BLL e DAL direttamente in alcuni scenari dove ha più senso quello che è noto come loose layering.

Per quanto riguarda CORE (Interfaces), penso che NON dovresti avere le interfacce BLL e DAL raggruppate insieme. Immagina una stratificazione rigorosa, in tal caso potresti non voler esporre le interfacce DAL all'interfaccia utente.

Riesco a vedere alcuni potenziali problemi con questo approccio,

1. Avere tutte le DTO in un progetto, Se hai un DTO utilizzato nel tuo livello di presentazione, perché dovresti inserirlo nell'assemblaggio principale, piuttosto li metterei a cui appartengono

2. Se il BLL è il modello di dominio, va bene, ma se anche i servizi ci vivono, preferisco spostarli sul livello di servizio tra UI e DAO.

Idealmente,
1. Dominio (BLL) 2. Repository (DAO) 3. Servizi (coordinatore di BLL e DAO) 4. UI

Uncle Bob dà discorsi su Clean Architecture .

Perché in realtà vuoi migliorare il tuo design, ti consiglio vivamente di ascoltare il suo parlare .

Ha sostenuto come il Principio di Responsabilità Unica si applichi non solo a una classe o un metodo, ma anche a come progettiamo la nostra architettura.

In particolare, dovresti cercare di raggruppare le cose che generalmente cambiano insieme e tirare cose che cambiano per motivi diversi.

Considera questa architettura:

- Core
   Dependencies
   class1
   class2
   .
   .
   .

- Stories
 - CreateUser
    Dependencies
    View
    ViewModel
    Repository
    Tests

 -  ShareStatusUpdate
    Dependencies
    View
    ViewModel
    Repository
    Tests

L'architettura sopra descritta impegna uno sviluppatore a comprendere immediatamente l'intento dell'architettura in base alla funzionalità che l'architettura espone chiaramente.

Si noti come questa architettura non oscuri la funzionalità del sistema attraverso l'uso di "Controllori" "Modelli", "DAL", ma espone invece le storie degli utenti che supporta in dettagli chiari come CreateUser e ShareStatusUpdate.

Quindi, l'architettura dovrebbe trasmettere facilmente la progettazione di un sistema senza che l'utente debba scavare attraverso le cartelle (cioè Controller, Modello, DAL) per comprendere la funzionalità desiderata. "Controllori", "Modelli" e "DAL" sono dettagli di basso livello di un'architettura e non "l'architettura" stessa.