Che cosa determina quando un'applicazione richiede mvvm?

Se la tua applicazione utilizza WPF o Silverlight, utilizza MVVM.

Non importa quanto sia semplice la tua applicazione. È un modello molto semplice da imparare e rende estremamente facili la manutenzione / gli aggiornamenti futuri. Rende anche così nuovi sviluppatori, o anche qualcuno che guarda il codice tra qualche anno può capire cosa sta succedendo rapidamente.

È sempre possibile costruire applicazioni su larga scala senza seguire uno schema di progettazione. Tuttavia, seguire un modello generalmente consente un maggiore disaccoppiamento dei sottosistemi e, quindi, aumentare la facilità di ridimensionamento del sistema.

Personalmente, io sempre seguo un modello durante lo sviluppo delle mie applicazioni, sia che si tratti di MVVM, MVC, HMVC o altri. Detto questo, adotterò un modello solo se ha senso per il progetto . Non vuoi seguire ciecamente un modello di progettazione solo perché qualcuno ti ha detto che è una buona idea :) Non sai mai veramente quanto le tue applicazioni diventeranno complesse nel tempo e verranno rilasciate. Quindi, nella mia mente, è sempre meglio prendere il tempo per costruire una solida base con un design che si adatti al sistema che sto costruendo (se ce n'è uno) piuttosto che costruire un framework personalizzato che potrebbe non scala bene alla fine della giornata e poi finisci con il codice di refactoring che avevo precedentemente scritto per adattarlo a uno di questi progetti.

Recentemente (lo scorso anno circa) ho usato MVVM su un progetto che assolutamente non ne aveva bisogno solo per impararlo. Oggi sono molto contento di averlo fatto.

L'applicazione non è estremamente complessa, ma la mia esperienza ora è che posso aggiungere nuove funzionalità in modo semplice e naturale anche se non ho toccato il codice per un po 'di tempo, molto più che negli altri miei programmi. MVVM è anche molto diffuso, quindi si utilizza un modello di progettazione per il quale si ottiene molto aiuto in caso di domande. Non sei solo con ciò, per così dire. ;)

Inoltre non ho aggiunto alcun test dato che finora era solo un progetto per animali domestici e oggi, dove è più usato di quanto pensassi, posso facilmente aggiungere test molto più comodamente di quanto potessi fare sin da quando ViewModels è semplicemente fantastico per il test.

In uno dei tuoi commenti hai menzionato un aumento del codice boilerplate che nella mia esperienza deriva principalmente dal fatto che molte persone pubblicano le loro proprietà dai loro Modelli solo nei loro ViewModels, duplicando molto codice nel processo. Io di solito implemento INotifyPropertyChanged nei miei Modelli per aggirare questo. Alcuni lo vedono come una cattiva pratica, ma questa è la sua bellezza, il modello di progettazione è ancora fresco e discusso (vedi l'opinione di Sasha Barbers su questo a al codeproject in" Sviluppare modelli usando Cinch ").

Quindi puoi assolutamente ignorarlo e scrivere ancora un ottimo software, ma ti consiglio di valutare attentamente i vantaggi che potresti perdere prima di farlo.

Generalmente MVVM non è un requisito, ma qual è l'alternativa? A nessuno piace lavorare con Spaghetti Code, e framework come MVVM light e PRISM lo rendono piuttosto facile da imparare. In realtà ho dovuto cambiare un modello e modificare la logica in un ViewModel questa mattina che ho scritto circa 9 mesi fa. Non dovevo toccare l'interfaccia utente, e potevo separare il problema in parti gestibili. Non è mai stato così complesso di un progetto, ma penso che sia in realtà più conveniente avere un accoppiamento lento. L'unico costo in tempo reale è nella fase di apprendimento. Sembra difficile però girarti per la testa, e poi un giorno poof , lo saprai e non vorrà mai più tornare sui progetti più banali.