Prism 4 WPF App - Architettura della soluzione con MVVM, repository e modelli di unità di lavoro implementati

Question

Sono nuovo di .Net e sto cercando di imparare le cose. Sto cercando di sviluppare un'applicazione WPF Prism4 con

1. Visual Studio 2010 Express Edition CSharp,
2. Prism v4,
3. L'unità come CIO,
4. SQL Server CE come archivio dati.

Ho studiato molto (?) E per contagiare anche da this e this tra gli altri, e ha deciso di implementare modelli di MVVM, Repository e UnitofWork. Questa applicazione sarà un'applicazione desktop con un singolo utente (me :-)

Così, ho creato una soluzione con i seguenti progetti:

1. Shell (Application layout e la logica di avvio)
2. comune (Application Infrastructure e del flusso di lavoro Logic)
3. BusinessModuleA (Viste e ViewModels)
4. BusinessModuleA.Model (entità di business - POCO)
5. BusinessModuleA.Data (Repository, DAT un Access (EF?))
6. BusinessModuleB (Viste e ViewModels)
7. BusinessModuleB.Model (Enti di affari - POCO)
8. BusinessModuleB.Data (Repository, Data Access (EF?))

Le mie domande sono:

1. Quali progetti devono fare riferimento a quali progetti?
2. Se si implementano i repository in "BusinessModuleX.Data", che è ovvio, dove dovrei definire gli IRepositories?
3. Dove dovrei definire IUnitOfWork e dove dovrei implementare UnitOfWork?
4. Va bene se consumo UnitOfWork e repository nel mio ViewModels? Instict dice che è un cattivo design.
5. Se (4) sopra non è corretto, ViewModel dovrebbe ricevere dati tramite un servizio Layer (un altro progetto?). Quindi, come possiamo tenere traccia delle modifiche alle entità in modo da richiamare i metodi CRUD rilevanti su quegli oggetti nel livello di servizio?
6. Qualcosa di tutto questo ha senso o mi manca l'immagine grande?

---

Ok, può essere che non stato chiaro su quello che volevo esattamente nel mio primo post. Non ci sono molte risposte in arrivo. Sto ancora cercando risposte perché mentre ciò che suggerito da @Rachel può essere efficace per le esigenze immediate, voglio stare attento a non dipingermi in un angolo. Ho un Access Db che ho sviluppato per uso personale in Office e che è diventato un successo e ora viene utilizzato da oltre 50 utenti e in crescita.Mantenere e modificare la base del codice di accesso è stato abbastanza semplice all'inizio, ma con l'evolversi della app, cominciò a crollare. Questo è il motivo per cui ho scelto di riscrivere tutto in .Net/Wpf/Prism e voglio essere certo di ottenere il giusto design di base.

Per favore discutete.

Nel frattempo, mi si avvicinò con this...

Answer 1

Prima di tutto, vorrei semplificare il vostro elenco di progetti un po 'a poco Shell, Common, ModuleA e ModuleB. All'interno di ogni progetto avrei sottocartelle per specificare dove si trova tutto. Ad esempio, ModuleA potrebbe essere separati in cartelle per Views, ViewModels, e Models

vorrei mettere tutte le interfacce e gli oggetti condivisi globali come IUnitOfWork nel progetto Common, dal momento che sarà utilizzato da tutti i moduli.

Come si implementa IUnitOfWork e il tuo Repositories dipende probabilmente da ciò che i moduli sono.

• se l'intera applicazione si collega a un database o gli oggetti di database di azioni, poi mi sarebbe probabilmente creare altri due progetti per la DataAccessLayer. Uno potrebbe contenere interfacce/classi pubbliche che possono essere utilizzate dai moduli e l'altro conterrebbe l'effettiva implementazione del livello di accesso ai dati, come Entity Framework.

• Se ogni modulo ha il proprio database o il proprio insieme di oggetti nel database (es. Oggetti Customer non esistono se non si ha il modulo cliente installato), quindi vorrei implementare IUnitOfWork nei moduli e hanno loro gestiscono il proprio accesso ai dati. Probabilmente avrei ancora alcune interfacce generiche nella libreria Common per i moduli da cui costruire.

Idealmente, tutti i moduli e il vostro Shell possono accedere alla libreria Common. I moduli non dovrebbero accedersi l'un l'altro a meno che non si basino su di essi. Ad esempio, un modulo Statistiche cliente che si basa sul modulo Base del cliente deve accedere al modulo Cliente.

Per quanto riguarda se i vostri ViewModels dovrebbero consumare un UnitOfWork o Repository, li avrei utilizzano un Repository solo. Idealmente il tuo Repository dovrebbe essere come una scatola nera - ViewModels può ottenere/salvare i dati usando lo Repository, ma non dovrebbe avere idea di come sia implementato. I repository possono ottenere i dati da un servizio, un framework di entità, l'accesso diretto ai dati o ovunque, e il ViewModel non gli interesserà.

Io non sono un esperto di progettazione dell'architettura, però è così che avrei costruisco :)

Answer 2

Mi raccomando di ottenere il modello Introduction to PRISM and Repository all'interno Design Patterns Library video di formazione. Sono grandi. Spero che aiuti