Lo schema MVVM è una parola scottante di recente e sto pianificando di imparare e rifattorizzare il mio progetto esistente in questo modello. Non ho esperienza e lungimiranza del rischio potenziale. Avete davvero ottenuto molti benefici dal Pattern MVVM in progetti reali? Vale la pena rifattorizzare un MVVM esistente (principalmente utilizzando i file Code-Behind) nel pattern MVVM?
Ho realizzato 4 progetti Silverlight e 1 progetto WPF per i clienti e tutti sono stati realizzati utilizzando il pattern MVVM. Quindi, per rispondere alla tua domanda, se è ampiamente adottato ... sì.
Vale la pena rifattorizzare un vecchio progetto per utilizzare il pattern MVVM? Dipende dal progetto. La testabilità è un fattore importante del progetto che senza dubbio è buona pratica convertire il progetto. Se il progetto è nella fase iniziale, consiglierei anche di utilizzare il pattern MVVM in quanto incoraggerà a produrre codice più pulito e meno abbinato. Il progetto esistente è in una fase avanzata e ci sono altri schemi coinvolti, quindi dipende dal budget e dal tempo del progetto se vale la pena convertirlo.
Solo un piccolo nodo laterale di me stesso. Più sto facendo uso di MVVM, più inizio a preoccuparmi della complessità che un viewmodel può ottenere e meno sono convinto che MVVM sia la strada da percorrere nelle applicazioni Silverlight / WPF. Trovo irritante avere i miei comandi e le proprietà dei dati nello stesso posto, perché non c'è più una sepperation pulita tra i dati e il comando. Per questo incoraggerei le persone a dare un'occhiata al pattern MVVMC che risolve questi problemi.
Ho trovato l'articolo con una buona spiegazione quando dovresti usare il pattern MVVM: link
Secondo l'articolo ci sono solo 3 reali vantaggi di MVVM:
Quindi se il tuo codice è chiaro e soddisfacente, il tuo team non ha designer, non scrivi test unitari - non ha senso cambiare l'architettura. MVVM non ha nulla a che fare con la qualità del codice, non è una bacchetta magica. Ma se inizi un nuovo progetto, può davvero aiutarti.
Sì, questo modello è un sogno durante la creazione di applicazioni WPF e Silverlight. L'ho usato su molti progetti, compresi quelli che sono app di produzione rivolte al pubblico e vorrei usarlo di nuovo se costruissi un'altra app WPF / Silverlight in futuro (lo userei anche nelle pagine Javascript tramite knockout.js libreria).
Il singolo grande vantaggio di MVVM è che la completa separazione di logica e dati dal layout lo rende testabile . Questo spesso non è un problema per i coder stand-alone , ma nel settore IT Sviluppo guidato da test (TDD) è ora un'abilità attesa.
Troviamo anche MVVM "ha più senso" dato che il codice tende ad essere più pulito e guardiamo i problemi da una prospettiva più ampia rispetto al vecchio "basta fare doppio clic e aggiungere ancora un altro gestore".
Dopo aver iniziato a lavorare su progetti di grandi dimensioni, consiglio vivamente anche di esaminare il framework / linee guida PRISM. Aggiunge un ulteriore livello di separazione che consente di sviluppare moduli di 100 da parte di team separati senza che questi si inciampino l'uno sull'altro in ogni momento.
L'unica cosa addizionale su cui mi tirerò il collo è: MVVM non preclude la necessità di classi di controller. Troviamo che fanno il punto più ragionevole per appendere la logica di risposta dell'applicazione (non in code-behind, non nel ViewModel e certamente non nei DataModels). Forse dovrebbe essere MVCVM? :)
Leggi altre domande sui tag wpf silverlight mvvm