In quali condizioni è appropriato l'uso di MVVM?

Model View View-Model è stato sviluppato da Microsoft per le piattaforme di sviluppo dell'interfaccia utente che supportano la programmazione basata sugli eventi, in particolare Windows Presentation Foundation (WPF) e Silverlight sulle piattaforme .NET utilizzando i linguaggi XAML e .NET. Negli anni successivi, molti framework Javascript come Angular, Knockout ed ExtJS hanno adottato il modello.

Come la maggior parte dei modelli di software, MVVM ha i suoi usi appropriati e i suoi abusi. In quali condizioni è appropriato l'uso di MVVM? Quando è sconsigliato?

MVVM è progettato per essere utilizzato laddove sono necessarie interazioni utente complesse utilizzando l'interfaccia utente ad alta fedeltà (ad es. WPF ).

MVVM si rivolge alle moderne piattaforme di sviluppo dell'interfaccia utente (Windows Presentation Foundation o WPF e Silverlight) in cui esiste uno sviluppatore di esperienza utente (UXi) che ha requisiti diversi da quelli di uno sviluppatore più "tradizionale" (ad esempio orientato verso la logica aziendale e sviluppo back-end). Il View-Model di MVVM è "fondamentalmente un convertitore di valore per gli steroidi", il che significa che il View-Model è responsabile dell'esposizione degli oggetti dati dal Modello in modo tale che tali oggetti possano essere facilmente gestiti e consumati. A questo proposito, View-Model è più Model che View e gestisce la maggior parte, se non tutta, la logica di visualizzazione della View.

MVVM è stato progettato per utilizzare funzioni specifiche in WPF per facilitare meglio la separazione dello sviluppo del layer View dal resto del pattern rimuovendo praticamente tutto il "code-behind" dal layer View. Invece di richiedere a Interactive Designers di scrivere il codice View, possono usare il linguaggio XAML di markup nativo WPF e creare collegamenti al ViewModel, che è scritto e gestito dagli sviluppatori di applicazioni. Questa separazione di ruoli consente a Interactive Designers di concentrarsi sulle esigenze di UX piuttosto che sulla programmazione o sulla logica di business, consentendo lo sviluppo dei livelli di un'applicazione in più flussi di lavoro.

Per le UI in cui questo tipo di interazione avanzata non è necessaria, MVVM potrebbe essere eccessivo; MVP può essere una scelta più naturale. Per le applicazioni Web, MVC è la soluzione migliore. Per applicazioni molto piccole che non cresceranno mai più grandi (come piccole utility Winforms), il code-behind è adeguato.

A volte MVVM può essere una trappola. Dalla mia esperienza favorisce applicazioni simili a CRUD (moduli su dati) rispetto a più interfacce utente orientate alle attività. Non sto dicendo che implica una cattiva architettura per il back-end / altri livelli nell'applicazione, ma ho visto molte applicazioni MVVM venire con l'architettura "DDD light". Non so perché esattamente perché l'associazione è così semplice ed è molto semplice configurare un'applicazione con un ORM e MVVM / Binding usando oggetti di dominio POCO / Anemic.

MVVM è un cerotto per livelli di associazione dati mal progettati. In particolare, ha visto molto uso nel mondo WPF / silverlight / WP7 a causa delle limitazioni nell'associazione dei dati in WPF / XAML.

D'ora in poi, assumerò che stiamo parlando di WPF / XAML poiché ciò renderà le cose più chiare. Vediamo alcune delle carenze che MVVM intende risolvere in WPF / XAML.

Forma dei dati vs forma dell'interfaccia utente

La "VM" in MVVM crea una serie di oggetti definiti in C # che si mappano su una serie di oggetti di presentazione definiti in XAML. Questi oggetti C # sono in genere collegati a XAML tramite le proprietà DataContext sugli oggetti di presentazione.

Di conseguenza, il grafico dell'oggetto viewmodel deve essere mappato sul grafico dell'oggetto di presentazione dell'applicazione. Questo non vuol dire che la mappatura debba essere una a una, ma se un controllo di elenco è contenuto da un controllo di finestra, allora ci deve essere un modo per passare dall'oggetto DataContext della finestra a un oggetto che descrive i dati di tale elenco.

Il grafico a oggetti viewmodel disaccoppia correttamente il grafico a oggetti modello dal grafico a oggetti dell'interfaccia utente, ma a spese di un layer viewmodel aggiuntivo che deve essere creato e gestito.

Se voglio spostare alcuni dati dalla schermata A alla schermata B, ho bisogno di giocare con i modelli di visualizzazione. Nella mente di un uomo d'affari, questa è una modifica dell'interfaccia utente. Esso dovrebbe avvenire esclusivamente nel mondo di XAML. Purtroppo, raramente può. Peggio ancora, a seconda di come sono strutturati i modelli di visualizzazione e di come i dati cambiano attivamente, potrebbe essere necessario un certo reindirizzamento dei dati per realizzare questa modifica.

Aggirare i dati inesprimibili

I binding WPF / XAML non sono sufficientemente espressivi. Fondamentalmente puoi fornire un modo per raggiungere un oggetto, un percorso di proprietà da attraversare e associare i convertitori per adattare il valore della proprietà dei dati a ciò che richiede l'oggetto di presentazione.

Se hai bisogno di associare una proprietà in C # a qualcosa di più complesso di quello, sei praticamente sfortunato. Non ho mai visto un'app WPF senza un convertitore di associazione che trasformava true / false in Visible / Collapsed. Molte app WPF tendono anche ad avere qualcosa chiamato NegatingVisibilityConverter o simile che inverte la polarità. Questo dovrebbe essere suonare campanelli d'allarme.

MVVM fornisce le linee guida per strutturare il codice C # che può essere utilizzato per ovviare a questa limitazione. Puoi esporre una proprietà sul tuo modello di vista denominata SomeButtonVisibility e limitarla alla visibilità di quel pulsante. Il tuo XAML è bello e carino ora ... ma ti sei trasformato in un impiegato - ora devi esporre + aggiornare i binding in due punti (l'interfaccia utente e il codice in C #) quando la tua interfaccia utente si evolve. Se hai bisogno dello stesso pulsante per essere su un altro schermo, devi esporre una proprietà simile su un modello di visualizzazione a cui tale schermo può accedere. Peggio ancora, non posso semplicemente guardare XAML e vedere quando il pulsante sarà più visibile. Non appena le associazioni diventano leggermente non banali, devo svolgere un lavoro investigativo nel codice C #.

L'accesso ai dati ha una portata aggressiva

Poiché i dati generalmente entrano nell'interfaccia utente tramite le proprietà DataContext, è difficile rappresentare i dati globali o di sessione in modo coerente in tutta l'app.

L'idea dell '"utente attualmente connesso" è un ottimo esempio: spesso è una cosa veramente globale all'interno di un'istanza della tua app. In WPF / XAML è molto difficile garantire l'accesso globale all'utente corrente in modo coerente.

Quello che mi piacerebbe fare è usare la parola "CurrentUser" nelle associazioni dei dati liberamente per fare riferimento all'utente attualmente connesso. Invece, devo assicurarmi che ogni DataContext mi dia un modo per raggiungere l'oggetto utente corrente. MVVM può adattarsi a questo, ma i modelli di visualizzazione saranno un disastro poiché tutti devono fornire accesso a questi dati globali.

Un esempio in cui cade MVVM

Supponiamo di avere un elenco di utenti. Accanto a ciascun utente, vogliamo visualizzare un pulsante "elimina utente", ma solo se l'utente attualmente connesso è un amministratore. Inoltre, agli utenti non è consentito cancellare se stessi.

Gli oggetti modello non dovrebbero conoscere l'utente attualmente connesso: rappresenteranno solo i record utente nel database, ma in qualche modo l'utente attualmente connesso deve essere esposto a associazioni di dati all'interno delle righe dell'elenco. MVVM impone che dovremmo creare un oggetto viewmodel per ogni riga dell'elenco che compone l'utente attualmente connesso con l'utente rappresentato da quella riga dell'elenco, quindi esporre una proprietà chiamata "DeleteButtonVisibility" o "CanDelete" su quell'oggetto viewmodel (a seconda delle tue sensazioni sui convertitori di associazione).

Questo oggetto assomiglierà moltissimo a un oggetto Utente in molti altri modi: potrebbe essere necessario riflettere tutte le proprietà dell'oggetto modello utente e inoltrare gli aggiornamenti a tali dati quando cambia. Questo sembra davvero icky - ancora una volta, MVVM ti rende un impiegato costringendoti a mantenere questo oggetto user-workalike.

Considera: probabilmente devi anche rappresentare le proprietà del tuo utente in un database, nel modello e nella vista. Se hai un'API tra te e il tuo database, allora è peggio: sono rappresentati nel database, nel server API, nel client API, nel modello e nella vista. Sarei davvero restio ad adottare un modello di progettazione che aggiungesse un altro livello che deve essere toccato ogni volta che una proprietà viene aggiunta o modificata.

Ancora peggio, questo livello si adatta alla complessità dell'interfaccia utente, non alla complessità del modello di dati. Spesso gli stessi dati sono rappresentati in molti punti e nell'interfaccia utente: questo non solo aggiunge un livello, ma aggiunge un livello con una superficie extra!

Come avrebbero potuto essere le cose

Nel caso sopra descritto, vorrei dire:

<Button Visibility="{CurrentUser.IsAdmin && CurrentUser.Id != Id}" ... />

CurrentUser sarebbe esposto a livello globale a tutti gli XAML nella mia app. L'ID si riferirebbe a una proprietà su DataContext per la mia riga di elenco. La visibilità si converte automaticamente da booleano. Qualsiasi aggiornamento a Id, CurrentUser.IsAdmin, CurrentUser o CurrentUser.Id attiverebbe un aggiornamento alla visibilità di questo pulsante. Vai tranquillo.

Invece, WPF / XAML obbliga i suoi utenti a creare un casino completo. Per quanto ne so, alcuni blogger creativi hanno schiaffeggiato un nome su quel casino e quel nome era MVVM. Non farti ingannare: non è della stessa classe dei modelli di design GoF. Questo è un brutto trucco per aggirare un brutto sistema di associazione dei dati.

(Questo approccio viene talvolta definito "Programmazione reattiva funzionale" nel caso in cui si desideri ulteriori letture).

In conclusione

Se devi lavorare in WPF / XAML, non consiglio ancora MVVM.

Volete che il vostro codice sia strutturato come nell'esempio sopra "come avrebbero potuto essere le cose" - il modello esposto direttamente alla vista, con espressioni di associazione dati complesse + coercizioni di valore flessibili. È molto meglio: più leggibile, più scrivibile e più gestibile.

MVVM ti dice di strutturare il tuo codice in un modo più dettagliato, meno gestibile.

Invece di MVVM, crea alcune cose per aiutarti ad approssimare la buona esperienza: sviluppa una convenzione per esporre lo stato globale alla tua interfaccia utente in modo coerente. Costruisci alcuni strumenti con convertitori di rilegatura, MultiBinding, ecc. Che ti consentono di esprimere espressioni di rilegatura più complesse. Costruisci una libreria di convertitori di binding per contribuire a rendere meno dolorosi i casi di coercizione comuni.

Ancora meglio: sostituisci XAML con qualcosa di più espressivo. XAML è un formato XML molto semplice per creare un'istanza di oggetti C #: non sarebbe difficile trovare una variante più espressiva.

Altra mia raccomandazione: non usare toolkit che forzano questo tipo di compromessi. Danneggeranno la qualità del tuo prodotto finale spingendoti verso merda come MVVM invece di concentrarti sul tuo dominio problematico.

Mi piace molto MVVM e trovo le sue sfide motivanti e vedo i numerosi vantaggi, ma ...

1. Per applicazioni o giochi che richiedono un sacco di UI / codice di interazione per aggiungere un sacco di comportamenti personalizzati mantenendo perfetto - spesso è meglio usare un MVVM un po 'sporco - usalo quando è utile o in più dati centrati rispetto a aree di interazione del codice. Supponi di voler creare un controllo e spostarlo tra diversi controlli padre o altrimenti memorizzarlo nella cache ...

2. Ha una curva di apprendimento piuttosto ripida, quindi a meno che tu non abbia tempo, prevedi di sviluppare molto in WPF / SL, avere progettisti esperti in Blend, sentire la necessità di scrivere un codice di prova per la tua UI o aspettarti di fare anni di manutenzione per la tua progetto - potrebbe non essere ripagato.

3. Non molti designer conoscono Blend, non tutti i progetti meritano di concentrare i test automatizzati sul livello di presentazione, poiché devono comunque essere testati manualmente ed è così che troverai i bug più importanti, non testando le VM.

4. È davvero un investimento. Devi prima capire le basi di WPF / SL e XAML, quindi capire come fare i collegamenti giusti, collegarti a vms in un certo ordine, ottenere il comando giusto, scegliere un framework nella maggior parte dei casi che potrebbe essere problematico a causa delle licenze, costruire una libreria di sippet per codificare in modo efficiente, solo per scoprire che la piattaforma non sempre funziona bene con i binding e che ha bisogno di creare una libreria di comportamenti che ti dia ciò di cui hai bisogno.

Nel complesso, però - se si superano tutti gli ostacoli e si diventa abbastanza carenti nel modello - tutto ripaga in chiarezza, manutenibilità e ... Vantarsi dei diritti? :)

Sono stato un programmatore WPF / Silverlight per anni costruendo enormi applicazioni, come i sistemi di trading, su MVVM.

Per me, con il passare degli anni, ho imparato che la MVVM rigorosa consuma tempo e costa denaro. Con rigoroso intendo regole come "nessun codice dietro".

È impossibile in tutto tranne l'app di base modulo / database, non avere code-behind.

Il progettista specificherà qualcosa nel primo giorno che non è possibile con i controlli standard, quindi è necessario creare una serie di controlli personalizzati o avvolgere i controlli esistenti per supportare il paradigma di interazione mentre si lavora con MVVM.

Ho scritto tutti i tipi di controlli dell'interfaccia utente swish usando matematica, inerzia, gesti ecc. E il suo duro lavoro.

Ma questo è tutto code-behind, semplicemente non è nella vista. Devi gestire i clic sui pulsanti, lo scorrimento, il trascinamento, ecc., Ma è tutto ben racchiuso in una serie di controlli, che in qualche modo rende ok questo codice.

Spesso è più semplice scrivere semplicemente il code-behind e le cose intelligenti dell'interfaccia utente nella vista, invece di creare un set di controlli solo per il gusto di farlo.

L'obiettivo di MVVM è quello di separare la logica applicazione / business dalla logica dell'interfaccia utente. Il sistema di associazione e MVVM è un bel modo per farlo.

Gli altri obiettivi propagandati, come il designer XAML su una scrivania, il programmatore C # dall'altra, uno che lavora in Blend l'altro in VS, è un errore.

Essere in grado di riprogettare rapidamente un'interfaccia utente è un altro errore. Non succede mai, la sua ottimizzazione prematura; qualsiasi grande rielaborazione richiede molto lavoro sui modelli di visualizzazione. La modifica è una cosa, ma non sono possibili revisioni rapide dell'interfaccia utente; i modelli di vista devono adattarsi al paradigma di interazione, quindi l'accoppiamento è più stretto di quanto tu possa immaginare.

Per me, utilizzo MVVM per mantenere la logica della mia applicazione separata (di solito utilizzo un controller testabile e una serie di modelli di vista senza logica) ma qualunque codice e trucchi siano necessari per rendere la mia UI simile e agire in modo sexy, non sudalo.

Altrimenti finirai per regnare nei tuoi progetti, animazioni fantastiche, ecc. Solo perché l'idea di come MVVM-realizzarlo tutto diventa troppo sbalorditiva.

MVVM, come la maggior parte delle cose nella vita, ha un punto debole tra due estremi.

La cosa più importante nella progettazione del software è spedire il tuo prodotto in anticipo, scoprire quali funzionalità vengono utilizzate, quale interfaccia utente funziona bene e non scrivere un bellissimo codice per un prodotto che nessuno usa.

Se l'applicazione richiede che si associ a quantità eccessive di dati in tempo reale, MVVM può effettivamente interferire perché sta introducendo astrazioni che rallentano il processo e, supponendo che stiamo parlando di WPF / Silverlight / WP7 in questo momento, l'associazione il motore non è attualmente così efficiente; anche se i miglioramenti sono in arrivo.

MVVM, così com'è, non è anche l'unica parte dell'equazione che devi considerare. MVVM puro deve essere supportato con infrastrutture come il modello Mediator per consentire la comunicazione tra ViewModel disconnessi.

Nonostante l'opinione di Blucz sopra, MVVM è in linea con i modelli GoF. Se dai un'occhiata ai pattern, MVVM è l'equivalente del pattern Model View Passive Presenter, che è apparso all'incirca nello stesso momento di MVVM. Qui spesso le persone si lamentano della complessità di MVVM semplicemente perché non capiscono come progettarlo utilizzandolo.

Un'altra area in cui ho riscontrato problemi con MVVM è quella in cui è necessario incorporare una tecnologia di terze parti non progettata per supportarla (come il framework UII per MS Dynamics). A volte devi chiederti se valga la pena o meno la pena di "hackerare" con l'altra tecnologia solo per lavorare con MVVM.

Se stai mescolando e abbinando qualcosa come Win Forms nella tua soluzione WPF, probabilmente quella parte della soluzione non sarà adatta anche per MVVM. Spero che questo ti dia un'idea di alcune aree in cui MVVM non è applicabile.

L'uso di MVVM non ha senso quando:

• Non stai lavorando con WPF o Silverlight
• Stai testando un concetto

Questo è tutto. Non riesco davvero a pensare al motivo per cui NON dovresti usare MVVM quando lavori con WPF / Silverlight, a meno che tu non stia testando o eseguendo il debug di qualcosa in un progetto separato. Trovo il modello di progettazione ideale per lo sviluppo di WPF / Silverlight a causa del modo in cui funzionano i collegamenti XAML.

Il punto centrale di MVVM è che l'intera applicazione viene eseguita nei ViewModels e le tue Views sono semplicemente un bel livello che gli utenti possono utilizzare per interagire con i tuoi ViewModels. Vuoi fare clic su un pulsante, stai effettivamente eseguendo un metodo ViewModel. Vuoi cambiare la pagina, stai effettivamente cambiando la proprietà CurrentPage in ViewModel.

Uso MVVM per tutto lo sviluppo di WPF / Silverlight, anche per piccoli progetti semplici a pagina singola, sebbene il modo in cui utilizzo MVVM differisca in base alle dimensioni del progetto e a ciò di cui ho bisogno. Una volta che ho fatto una piccola app senza MVVM, ho finito per pentirmi (in seguito è stato refactored per utilizzare MVVM durante l'aggiunta di un aggiornamento)

Ho fatto un po 'di lavoro per un cliente su un progetto che era in codice con un tentativo di convertire in MVVM lanciato ed era un casino enorme. Questo non vuol dire che tutti i progetti code-behind siano un casino. Le visualizzazioni potrebbero causare errori o arresti anomali di Blend che causava problemi ai progettisti.

Mi sono dilettato con RoR e ho praticamente saltato qualsiasi cosa con ASP.NET Webforms ma quando uscì ASP.NET MVC ho cercato di imparare il più possibile, spesso usando i libri ASP.NET MVC In Action e codecampserver come riferimento . Sebbene sia un modello diverso, utilizzo molte delle cose che ho imparato dai libri di In Action nello sviluppo di SL / MVVM.

Quando ho iniziato a lavorare con Silverlight sono rimasto sorpreso da quanto fosse nudo e mi è sembrato un requisito scegliere uno dei tanti framework disponibili per vestirlo. Vedo questo come un problema con le persone che rinunciano all'apprendimento di MVVM.

Ho iniziato con l'eccellente MVVM-Light che mi ha aiutato a ottenere una comprensione venduta del modello. Successivamente ho iniziato a lavorare con Caliburn Micro e poi le luci si sono accese. Per me Caliburn Micro è come usare ASP.NET MVC su ASP.NET Webforms. Quindi, anche per piccole applicazioni di esempio, creo il progetto, NuGet CM, e sono fuori e funzionante. Seguo il primo approccio di ViewModel e mantengo la mia vista stupida e facile da usare in Blend. Le mie VM sono testabili se ci sei dentro e con CM è abbastanza facile spostarsi attorno a layout di schermo complessi.

Potresti provare questa alternativa. Questa opzione elimina il modo WPF di database, datatemplate e MVVM. Questa opzione è più simile all'approccio WinForms designer.cs vecchio, semplice e affidabile.

Compositi WPF

http://wpfcomposites.codeplex.com/

Qui, il conciso code-back C # per WPF viene prodotto sovrapponendo una semplice matrice in cima all'interfaccia utente tramite compositi basati su griglia. Se una moderna interfaccia utente XAML contiene solo alcune etichette di testo e una casella di riepilogo di foto, perché questo non può essere definito dalla semplice riga di codice: grid.AddText (guid, x coordinate, y coordinate)? Nota, questo non è su una tela, ma ancora all'interno dei contenitori WPF: griglia, dockpanel, ecc. WPF è estremamente potente. Questo approccio si limita a sfruttare questo.

Gli sviluppatori in genere non si occupano di matrici e indici. Iniziare con un livello di contenitore a grana grossa definito dal GUID degli oggetti di trasferimento dati (DTO) o POCO, quindi completare questi contenitori con chiave con una matrice a grana più fine di potenziali righe e colonne all'interno?

Il suddetto progetto codeplex introduce questo approccio iniziando con il controllo ListBox ma si sta espandendo per coprire tutti i controlli compositi WPF. Ad esempio, ogni listboxitem è un composito aggiunto con un GUID (un composito lega uno a uno a una classe), quindi all'interno di questo elemento è presente una griglia su cui elementi dell'interfaccia utente figlio (i bambini associano uno a uno alle proprietà in una classe) può essere aggiunto a piacere tramite code-behind. I bambini potrebbero essere blocchi di testo o immagini.

L'idea è quella di sfruttare gli indici e una struttura di elementi dell'interfaccia utente ben definita (impone un oggetto ListBox a tema PresentationFramework.Aero come base da cui iniziare) invece che piastre di dati. Questo nuovo approccio limita di proposito ciò che si può fare, ma in questo modo si ottiene un codice C # conciso, solido e intuitivo, intuitivo. Non è necessario cercare soluzioni con modelli di controllo per lo stile di una barra di scorrimento o ingombrare una soluzione con più modelli di dati per attività semplici.

MVVM si basa principalmente sul framework dell'interfaccia utente che sto utilizzando. Quindi, con qualcosa come WPF o Silverlight che ha un paradigma basato sull'associazione a un datacontext, quel datacontext potrebbe sempre essere chiamato un modello di vista.

Quindi la domanda per me è quando costruisci una grande classe separata che è il modello di vista per questo controllo / finestra / applicazione e quando puoi cavartela usando gli oggetti che sono già stati creati.

Quindi abbiamo una domanda classica sull'aggiunta di uno strato di astrazione. la VM aggiungerà peso, inerzia e struttura a un progetto. Renderà più semplice la costruzione, ma più difficile da cambiare e più lungo da costruire. Nessuna di queste cose è facilmente quantificabile.

Per una risposta economica, MVVM non è appropriato per le app della riga di comando o i servizi Web :)