Dopo 2 anni, sto ancora lottando con MVVM come metodo pratico per produrre software funzionante. In alcuni casi è fantastico. Ho fatto un'applicazione multithread che controllava una piccola catena di montaggio che sarebbe stata una notte senza concetti MVVM. Un'astrazione dalla catena di montaggio fisica era quasi un gioco da ragazzi.
Tuttavia, la mia carriera ruota principalmente attorno alla linea di applicazioni aziendali interne - formalizzando e ottimizzando le operazioni di un'azienda. In tali app, c'è in generale un business teir che ruota attorno a CRUD e operazioni composte. In LOB, i miei modelli di vista finiscono per essere una raccolta molto semplice di funzioni di wrapper di una riga dei metodi della classe business e alla fine finiscono per complicare le attività più semplici come mostrare una finestra di messaggio o aprire una finestra. Qualcun altro non lo trova strano quando le persone si iscrivono a lunghe descrizioni di "dipendenza da iniezione" e "fornitori di messaggi" per una chiamata a Window.ShowDialog che esiste da decenni? Quante altre domande ci sono sull'overflow dello stack chiedendo consigli per attività estremamente semplici in winforms?
Non fraintendetemi: ricevo MVVM e come potrebbe essere inestimabile per i grandi team fare lo sviluppo orizzontale di un pacchetto software confezionato e commercializzato. L'unità di test dei modelli di visualizzazione potrebbe risparmiare milioni evitando un bug di RTM errato e gli sviluppatori di UI dedicati potrebbero offrire un'esperienza ricca. Ma quando il costo della ridistribuzione è minimo e tutte le aziende si preoccupano di pagare è un semplice software funzionante, perché dovrei passare il tempo a testare un'unità un semplice vm "wrapper" quando la mia logica aziendale è già testata? Quanto tempo mi permetterò davvero di spendere su animazioni e combinazioni di colori carini? C'è ancora qualcosa da fare per uno sviluppatore junior (rintracciare un bug in una funzionalità di salvataggio usata per guardare "Save_Click", ma ora devi capire i pattern e il progetto nel suo insieme soprattutto se ti affidi ai template per sposare la VM con la vista).
Certo, mi piace molto il database di WPF. Per approfittarne, imposto il contesto dei dati alla finestra stessa, dove ha accesso alla classe business e alle altre proprietà osservabili. Sì, interrompo quasi ogni "regola" MVVM facendo così. Ma almeno ho un semplice codice basato su eventi che è facile da leggere E posso trarre vantaggio dal nuovo database e dalla convalida. Il problema è nei designer - che non uso molto ma spero che ora sia integrato meglio nel 2012 - il designer mostra le centinaia di proprietà che hanno una finestra e le sue classi base.
Per quelli che possono riguardare puoi indicarmi risorse, libri o anche solo cambiamenti di prospettiva che rendano questo più facile da digerire. Darò un'altra volta a MVVM, ma l'ultima volta mi sono sentito piuttosto stupido a preoccuparmi dell'iniezione di dipendenza solo per mostrare una finestra di messaggio da una VM che non avevo intenzione di testare le unità. Anche se facessi un test unitario, otteniamo davvero più qualità scambiando test di run time per errori di compilazione di quelle temute applicazioni "strettamente accoppiate"?
Mi rendo conto che una risposta è rimanere semplicemente in winforms. Ma come uno degli ultimi sostenitori di WebForms (ho molta della stessa critica alla tendenza dello sviluppo del web), mi sono sentito un po 'come un dinosauro, perché quando ho scoperto non ci sono più WebForm nelle tracce delle certificazioni Microsoft. Andare avanti è l'unica opzione, anche se non mi piace.