MVVM è obsoleto in WPF? [chiuso]

16

Al momento sto provando a farmi girare per MVVM per il WPF - non intendo farmi girare la testa intorno al concetto, ma attorno ai veri e propri dadi di fare qualsiasi cosa che sia fuori dai sentieri battuti piuttosto che stupida CRUD.

Quello che ho notato è che molti framework e la maggior parte / tutti i post del blog provengono da "anni fa".

Questo perché ora è vecchio cappello e i blogger sono passati al Next Big Thing, o semplicemente perché hanno detto tutto quello che c'è da dire?

In altre parole, c'è qualcosa che mi manca qui?

    
posta Benjol 29.05.2013 - 14:39
fonte

2 risposte

4

MVVM non è obsoleto, ma è stato sovrascritto per cominciare. Non mi è mai piaciuto e mi ha tenuto in WinForms per troppo tempo; non riuscendo a vedere la foresta per gli alberi, ho buttato via il bambino con l'acqua sporca. Ora ho WPF, e ho l'idea di non voler mischiare il codice con il markup, ma preferisco lo stile Android di incollare il markup in un punto e dereferenziarlo con i cast del mio codice (che puoi anche fare in WPF, anche anche se non è mai stato trendy farlo per qualsiasi motivo).

In questo modo ottieni un controllo più preciso e non devi preoccuparti di tutto il controllo "onchanged" ovunque. Ritengo che questo sia più verificabile perché i test non sempre lo catturano se perdi un evento "onchanged".

Perdi un po 'di "dichiarativo" -ness, che sembra essere una tendenza in questi giorni (ad esempio se due widget sono mappati allo stesso valore, in MVVM puoi farlo, mentre con il codice imperativo devi impostare entrambi individualmente). Ma anche con MVVM, funziona solo nel caso umile. Se qualche widget deve visualizzare il log di un altro widget, devi scrivere un altro handler e un altro evento "onchanged" e così finisci per dover allungare la definizione di "dichiarativo" per dire che è così.

Aggiornamento 2015

WPF MVVM era (r) evolutivo per il suo tempo. Come era WPF. Ma entrambi avevano le loro verruche. Il WPF normale ne aveva incorporato troppo (in più era basato su XML) ed era piuttosto difficile da affrontare. (In realtà, se WPF avesse appena adottato un approccio più "bibliotecario" piuttosto che un approccio "quadro", avrebbe potuto trasformarsi in alcune cose davvero interessanti e l'intero universo tecnologico potrebbe essere completamente diverso ora). La idea di MVVM è stata fantastica, ma provare a montare un MVVM in WPF è stato in qualche modo un hacker poiché 1) C # non poteva davvero esprimerlo senza un sacco di caratteri standard e 2) I cimeli di WinForms come i popup modali erano ancora ideologicamente prevalente ma non potrebbe essere facilmente rappresentato in MVVM. Così tutto ha succhiato.

Detto questo, è ancora l'unica opzione realistica su Windows quando hai bisogno di trasparenza o GPU per le app LOB.

React ha ovviamente reso MVVM obsoleto. Sono rimasto deluso dal fatto che VS2015 non avesse un contatore nativo. Per ora siamo ancora bloccati usando il WPF grezzo (che è OK, ma sembra vecchio (sembra davvero proprio come vecchio come Winforms ora), e non ha un sacco di funzionalità built-in (si sente come un progetto interessante ma abbandonato) o con-MVVM, che a questo punto sembra un sovraccarico per niente, dal momento che anche buon MVVM (angolare 1) è stato esposto per i suoi difetti.

Eviterei WPF MVVM. È un livello in più, e nessuno se ne preoccupa più.

    
risposta data 17.10.2013 - 18:04
fonte
2

Tutto sommato, esiste un limite a ciò che puoi fare con un framework MVVM.

Sono "completati" poiché WPF non è stato spostato da quando è stato rilasciato da Microsoft. Se ci fossero aggiornamenti alla tecnologia, anche le librerie avrebbero bisogno di essere aggiornate. Questo non è successo.

    
risposta data 29.05.2013 - 14:41
fonte

Leggi altre domande sui tag