2010-06-01 4 views
7

Sono nella fase di completamento di un progetto di grandi dimensioni con diversi componenti di grandi dimensioni: acquisizione immagini, elaborazione immagini, memorizzazione dati, I/O di fabbrica (progetto di automazione) e molti altri.MVVM ed evitare oggetto Monolithic God

Ciascuno di questi componenti è ragionevolmente indipendente, ma per l'esecuzione del progetto nel suo complesso è necessaria almeno un'istanza di ciascun componente. Ogni componente ha anche un ViewModel e View (WPF) per monitorare lo stato e cambiare le cose.

La mia domanda è il metodo più sicuro, più efficiente e più gestibile per creare un'istanza di tutti questi oggetti, sottoscrivere una classe per un evento in un altro e avere un ViewModel e una vista comuni per tutto ciò.

Sarebbe meglio se ho una classe chiamata Dio che ha un'istanza privata di tutti questi oggetti? L'ho fatto in passato e me ne sono pentito.

O sarebbe meglio se Dio si affidasse alle istanze di Singleton di questi oggetti per far rotolare la palla.

In alternativa, se Program.cs (o dovunque sia Main (...)) istanzia tutti questi componenti e li passi a Dio come parametri e poi Lascio che lui (snicker) e il suo ViewModel si occupino dei dettagli della corsa questo progetti.

Qualsiasi altro suggerimento mi piacerebbe sentire.

Grazie!

risposta

2

Il mio metodo preferito per ottenere ViewModels è utilizzare ViewModelLocater. In sostanza è l'oggetto Dio come te implica, ma è solo responsabilità è quella di creare ogni ViewModel e mantenere un riferimento ad esso. Io di solito aggiungere il VML alle risorse del app e ogni vista è responsabile per l'impostazione è DataContext al ViewModel corretta. Se ti sei abbonato più eventi è possibile avere il vostro VML cablatelo manualmente, oppure può creare la VM che lancia gli eventi prima e passarlo ai dipendenti VM in esso di costruttore.

+0

Ho provato ogni approccio non di terze parti là fuori, ogni tentativo tranne l'ultimo è in qualche modo un fallimento, e alla fine si è risolto su qualcosa molto vicino al tuo modello ViewModelLocater. Sono sicuro che i quadri di terze parti pubblicati dagli altri ragazzi mi avrebbero risparmiato un sacco di lavoro, ma ero troppo tardi nel progetto per questo. Questa risposta è una buona via di mezzo. Suppongo che tu abbia imparato anche tu. Comunque, eccoci alcuni mesi dopo, grazie! – bufferz

0

Spero di aver capito bene la tua domanda. Penso che usare God Viewmodel non sia una buona idea. è meglio avere un unico ViewModel per ognuno dei vostri punti di vista e istanziare tutti i relativi ViewModels in quella ViewModel. quindi è possibile utilizzare un mediatore per inviare messaggi tra i modelli di visualizzazione di quella vista e altre viste, in modo rapido. anche io propongo di usare comandi wpf invece di eventi. è possibile trovare un articolo dettagliato sul mediatore in here.

3

Queste preoccupazioni sono curati molto bene con Microsoft "Composite Application Library" (aka Prism) un framework per lo sviluppo di compositi applicazioni WPF:

http://msdn.microsoft.com/en-us/library/ff647752.aspx

http://msdn.microsoft.com/en-us/library/ff648611.aspx

  • Composizione le tue viste: Prism ha un concetto di finestra di shell dell'applicazione e un gestore di zona. La shell agisce come una pagina di layout bare-bone in cui definisci le regioni con nome place-holder, ad es. "MainMenu" e "TabInterface". Aderisci i riferimenti alle viste e ai modelli di visualizzazione nelle classi di moduli, ad es. "MainMenuModule" e "TabInterfaceModule", e definire quale regione il modulo deve essere associata. Prism creerà le tue viste e le inserirà nelle regioni della shell all'avvio dell'applicazione. Ciò ti consente di comporre le tue viste indipendentemente l'una dall'altra.

  • Comunicazione tra i modelli di visore: Prism supporta un modello di mediatore denominato "Aggregatore di eventi". Fondamentalmente puoi pubblicare e iscriverti ai messaggi tramite l'agregator di eventi dai tuoi viewmodels. Ciò consente a viewmodels di comunicare liberamente tramite messaggi, piuttosto che dover conoscere l'uno dell'altro e gli eventi di hooking.

sostenitori Prism e supporta modelli per lo sviluppo di componenti indipendentemente l'uno dall'altro in modo debolmente accoppiati, senza introdurre oggetti Dio e oltre accoppiamento. Gran parte del Prisma è anche l'uso di IOC e l'iniezione delle dipendenze, quindi anche il test delle unità diventa molto più facile.

ho trovato il seguente articolo una buona introduzione pratica per utilizzare Prism e MVVM:

http://www.developmentalmadness.com/archive/2009/10/03/mvvm-with-prism-101-ndash-part-1-the-bootstrapper.aspx

3

Date un'occhiata ad alcuni quadri iniezione di dipendenza, come l'Unità (che utilizza CAL), Castello di Windsor o di primavera. NETTO.

1

È possibile utilizzare Controller (ApplicationController, Use-Case Controllers) anziché una classe "God". I controllori sono responsabili della creazione degli oggetti ViewModel e mediano tra di essi.

Come funziona viene mostrato dal progetto WPF Application Framework (WAF).