Architettura dell'applicazione MVVM, dove mettere la classe di configurazione di injection dependency, BusinessLayer e le interfacce Common?

Question

Architettura dell'applicazione MVVM, dove mettere la classe di configurazione di injection dependency, BusinessLayer e le interfacce Common?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

2

Pianificazione della mia architettura per un'applicazione MVVM Arrivo a questo:

MyApp.UI
- Visualizza
MyApp.BusinessLayer
- ViewModel
MyApp.DataAccessLayer
- RepositoryImplEF
MyApp.DomainLayer
- DomainObject
- RepositoryInterface
MyApp.Common
- Accesso
- Sicurezza
- Utility (contiene un metodo di riflessione usato da molti livelli)
- CustomException
MyApp.UnitTest

Mi sono ispirato al design guidato dal dominio, allo sviluppo basato sui test e all'architettura di cipolla, ma non sono sicuro di aver fatto tutto bene.

Non sono sicuro di un paio di cose:

dove mettere la classe di configurazione di dipendenza dipendenza? Nel progetto comune?
dove inserire le interfacce BusinessLayer? nel livello di dominio?
dove mettere le interfacce comuni? nel livello del dominio? Ma Common in riferimento al dominio (per alcune utilità di reflection e per DI se la risposta a 1. è sì) e il riferimento circolare non è buono

c# domain-driven-design dependency-injection architecture mvvm

posta gt.guybrush 16.09.2013 - 15:06

fonte

3 risposte

Leggi altre domande sui tag c# domain-driven-design dependency-injection architecture mvvm

Scheduling multilivello (MQS) con Round Robin Ripensare la strategia di test

score 1 · Answer 1

Abbiamo un'applicazione MVVM abbastanza grande che ho aiutato a progettare. Abbiamo un singolo progetto noto come l'host. questo sarà l'eseguibile principale per l'intera applicazione e contiene Bootstrapper per l'iniezione delle dipendenze.

MyApp.Host
- bootstrap
- Configura contenitore per tutte le dipendenze
- Esegue l'applicazione principale

Inoltre avevamo librerie di classi separate per tutte le nostre interfacce, quindi avremmo:

MyApp.ViewModels.Interfaces

Ciò consentirà alla tua applicazione di non avere riferimenti circolari in quanto sarà solo l'app Host che deve conoscere la relazione tra i tuoi modelmodelli e le interfacce.

score 0 · Answer 2

Comune è la soluzione migliore perché l'informazione è indipendente dalle responsabilità che i livelli MVVM rappresentano.
Sì, livello dominio / ViewModel. Quell'area possiede la logica del business, quindi dovrebbe avere le interfacce.
Interfacce comuni per cosa? Le interfacce appartengono al livello che detiene la responsabilità per l'azione rappresentata dalle classi.

Gli altri livelli faranno riferimento al livello comune. Lo strato comune non dovrebbe avere bisogno di fare riferimento a qualcosa all'interno degli altri livelli (altrimenti non sarebbe comune). Pensa attraverso quali sono le responsabilità per ciascun componente e dovresti essere in grado di identificare più facilmente dove le cose appartengono.

Se la sfida è con le tue classi di configurazione DI, allora hai bisogno di separarle. Una classe di configurazione master dovrebbe vivere all'interno del livello comune. Potrebbe essere necessario creare una configurazione specifica del livello su ogni livello.

score 0 · Answer 3

L'inizializzazione del contenitore IoC si trova di solito nel bootstrapper. Questa classe fa parte dell'infrastruttura / inizializzazione e in realtà non appartiene a nessuna cosa "comune". Dato che non hai intenzione di lavorare con il tuo modello di dominio tramite messaggistica / servizi ma usando BL / DAL, ti consiglio vivamente di inserire i contenuti di IoC nei moduli, assumendo che tu usi un contenitore che supporti i moduli. In questo modo puoi mantenere il tuo bootstrapper sottile e le tue registrazioni per modulo e i moduli si trovano in progetti corrispondenti.

Riguardo al BL, la domanda è: cosa pensi di mettere lì. Se il tuo modello di dominio è anemnico, avrai enormi progetti di "manager" aziendali con tutte le logiche concentrate lì. Non chiamerei questa parte del tuo modello di dominio. Se, al contrario, il tuo modello di dominio è pianificato per essere un modello ricco, avrai una serie di comportamenti nelle classi di dominio per definizione. Il resto della logica aziendale verrebbe separato da convalide complesse, comandi e query. Quelle che chiamate DAL con repository sono di fatto query. Preferirei provare a implementare CQRS.