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 nightmere 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 interna di applicazioni aziendali - formalizzando e ottimizzando le operazioni di un'azienda. In tali app, esiste generalmente un'impresa che ruota attorno al CRUD e alle operazioni complesse. Nei LOB, i miei modelli di vista finiscono per essere una raccolta molto semplice di funzioni di un line wrapper dei metodi della classe business e alla fine complicano solo le attività più semplici come mostrare una finestra di messaggio o aprire una finestra. Nessun altro trova strano quando le persone fanno lunghe descrizioni di "iniezione di dipendenza" e "provider di messaggistica" per una chiamata Window.ShowDialog che esiste da decenni? Quante altre domande ci sono sullo stack di overflow che richiedono consigli per attività estremamente semplici nelle winform?
Non fraintendetemi: ottengo MVVM e come potrebbe essere prezioso per i team di grandi dimensioni che svolgono lo sviluppo orizzontale di un pacchetto software ridotto e commercializzato. I test unitari dei modelli di visualizzazione potrebbero salvare milioni evitando un cattivo bug RTM e sviluppatori di UI dedicati potrebbero offrire una ricca esperienza. Ma quando il costo della ridistribuzione è minimo e tutto ciò che l'azienda si preoccupa di pagare è un semplice software funzionante, perché dovrei dedicare del tempo all'unità di test di un semplice "wrapper" quando la mia logica aziendale è già testata dall'unità? Quanto tempo mi permetterà davvero di dedicarmi a animazioni e combinazioni di colori carine? C'è ancora qualcosa da fare per uno sviluppatore junior (rintracciare un bug in una funzionalità di salvataggio utilizzata per guardare "Save_Click",
Certo, mi piace molto il databinding di WPF. Per trarne vantaggio, ho impostato il contesto dei dati sulla finestra stessa, dove ha accesso alla business class e a qualsiasi altra proprietà osservabile. Sì, infrangendo quasi tutte le "regole" di MVVM così facendo. Ma almeno ho un semplice codice guidato dagli eventi che è facile da leggere E posso sfruttare il nuovo database e la convalida. Il problema è nei progettisti - che non uso molto, ma spero che ora sia meglio integrato nel 2012 - il progettista mostra le centinaia di proprietà di una finestra e delle sue classi base.
Per quelli che possono relazionarmi, puoi indicarmi risorse, libri o anche solo cambiamenti di prospettiva che hanno reso più facile la deglutizione. Darò un'altra possibilità a MVVM, ma l'ultima volta mi sono sentito piuttosto stupido per 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 ho fatto il test unitario stiamo davvero ottenendo più qualità scambiando i test di runtime per errori di compilazione di quelle temute applicazioni "strettamente accoppiate"?
Mi rendo conto che una risposta è semplicemente rimanere in winform. Ma come uno degli ultimi sostenitori di WebForms (ho più o meno la stessa critica della tendenza dello sviluppo del web), mi sono sentito un po 'come un dinosauro come lo è quando ho scoperto che non sono rimasti più WebForms nelle tracce di certificazione Microsoft. Andare avanti è l'unica opzione, anche se non mi piace.