Attualmente sto lavorando su un'applicazione LOB che sto basando sull'architettura MVVM. Seguendo le risposte alle domande che sto ponendo, sembra che non ci siano molte persone che creano applicazioni grandi e / o complesse in MVVM.
Speriamo che ci sia un numero di voi che hanno costruito tali animali. In tal caso, hai scoperto che MVVM è in scala?
Ho lavorato su più progetti di grandi dimensioni su scala aziendale e MVVM è stata la chiave per mantenerli scalabili e controllabili. Non riesco a immaginare di avere team di progettazione e sviluppo separati in grado di lavorare in vero parallelo senza il flusso di lavoro abilitato dal pattern, né saremmo stati in grado di far dividere il team tra livelli, cioè avere qualcuno che codifica il livello WCF / servizio, un altro gestisce i modelli di vista, un altro lavoro sulla persistenza, ecc., con test unitari per aiutare con il refactoring e persino con i test di integrazione prima che altri livelli diventassero disponibili.
Non ho iniziato con MVVM perché era un pattern molto popolare, l'ho selezionato quando ho dovuto passare a un'applicazione massiva di Silverlight e ho cercato il modo migliore per gestirlo.
I progetti includono un importante strumento di social media networking per Microsoft chiamato Looking Glass, il sistema di monitoraggio dello stato di back-end che gestiva le Olimpiadi Invernali di Vancouver 2010 per Microsoft, una complessa dashboard SharePoint per la gestione dei rischi con integrazione Silverlight per PriceWaterhousecoopers e il lettore Blio (KNFB ) che funziona sia su WPF che su Silverlight. Questi sono solo quelli di cui posso parlare. Le dimensioni del team variavano da poche a dozzine di sviluppatori e progettisti che lavoravano contemporaneamente.
Se le persone incontrano difficoltà nel ridimensionare grandi progetti con MVVM, o se li rallenta piuttosto che accelerare la consegna, stanno semplicemente sbagliando.
Direi anche che se si visualizzano 100 campi su un singolo display, si potrebbe voler chiamare un team di progettazione perché non conosco molti umani che possono elaborare tante informazioni contemporaneamente. Nei database con migliaia di informazioni, la bellezza di Silverlight è l'estrazione e la presentazione di tali informazioni in modo che l'utente sia in grado di gestire le informazioni sullo schermo in blocchi di dimensioni ridotte. Inoltre, se stai caricando manualmente questi campi, di nuovo, non stai semplicemente sfruttando gli strumenti e i modelli disponibili. In un progetto mi ci sono volute 2 ore per creare un generatore che potesse sputare le classi di base e quindi la logica aziendale era sovrapposta. Un breve investimento in anticipo per uno sviluppo più rapido sul back-end.
Norma tipica: se stai ripetendo la stessa cosa centinaia di volte, vai a trovare uno strumento o costruisci uno per automatizzarlo.
Attualmente sto lavorando a un'applicazione aziendale che utilizza pattern MVVM con DDD. Questa è la mia esperienza personale:
Sono d'accordo sul fatto che MVVM sia stato la chiave per il successo di diverse applicazioni su scala aziendale su cui ho lavorato. La struttura coerente, la testabilità, ecc. Semplificano notevolmente il lavoro in un ambiente di squadra. C'è una buona curva di apprendimento che va bene, specialmente dal momento che ci sono tante interpretazioni del pattern come articoli, ma una volta capito, i vantaggi saranno evidenti.
Potresti aspettare 8 mesi perché il mio libro esca, ti spiegherò tutto lì;)
Non c'è nulla su MVVM stesso che impedisca il ridimensionamento. C'è molto su di esso che consente il ridimensionamento. Non solo in termini di prestazioni delle app, ma anche in termini di quanta funzionalità può essere compresa e navigata dagli sviluppatori a causa del modo in cui separare esplicitamente le preoccupazioni semplifica la logica dell'applicazione.
Leggi altre domande sui tag architecture mvvm