Ho sentito parlare di WPF, Silverlight ma poi ci sono anche Windows RT, Metro stuff, Windows 8 e così via al momento - sto facendo fatica a inchiodare su cosa scommettere.
Come faccio, in un dato momento, a trovare la migliore piattaforma per fare GUI alquanto a prova di futuro?
Guardando le tendenze attuali di Microsoft, non puoi rendere la tua interfaccia utente a prova di futuro se la stringa su un dato framework. Hai bisogno di qualche astrazione per rendere la tua applicazione a prova di futuro, e ci sono buoni schemi di progettazione per questo (vedi Modello -View-Presenter e Model-View-ViewModel ).
Se non hai bisogno di un controllo preciso su come le cose sembrano esattamente, puoi avere una struttura generica della UI come wxWidgets , QT e SWT o un framework che ti aiuta ad evitare troppo vincolante per il tuo framework UI, qualcosa come Caliburn Micro .
How do I, at a given point in time, find the best platform for doing somewhat future-proof GUI?
INMO, questo è un obiettivo desiderabile ma né realistico né ben definito.
Non è ben definito perché dovresti davvero quantificare la parte "futura". Non è realistico perché la storia ci dice che le tecnologie GUI sono le più veloci da cambiare e le loro modifiche sono radicali.
Tornando alla tua domanda, è necessario capire perché questo è importante nelle applicazioni della vita reale. Vedete, anche le tecnologie meno recenti non vengono sempre abbandonate improvvisamente e il live per molto tempo. I fornitori di controlli stanno ancora fornendo aggiornamenti ai componenti della GUI dell'applicazione Windows Form. Oggi puoi sviluppare un'applicazione basata su touch utilizzando Windows Form. Qualcosa che probabilmente non puoi fare con il nuovo Silverlight più recente nativo!
La prima cosa che farei è decidere l'ambiente utente che ci si aspetta. Successivamente, identifico i tipi di dispositivi su cui l'applicazione deve essere eseguita (applet, cellulari, Web, desktop, ecc.), Quindi controlli le lingue e gli strumenti di supporto.
WPF e Silverlight continueranno a vivere, anche se potrebbero non essere la calamita per i dollari di miglioramento. XAML, in qualche modo, sarà usato nel mondo di Windows 8. se pensi lungo il percorso di Silverlight, controlla la matrice dei Requisiti di sistema su MS-Silverlight .
Lo sviluppo di un'applicazione che non dipende dalla GUI, non sembra molto realistico per molte applicazioni commerciali commerciali, almeno. La complessità extra è molto difficile da giustificare. Ciò che gli uomini d'affari a volte tendono a scoprire è che la tecnologia sopravvive al modello di business su cui sono basate alcune applicazioni. (Ricordo un progetto che abbiamo fatto per una grande banca che è vissuta per 3 mesi solo perché un'altra banca ha acquisito quello per il quale abbiamo realizzato il progetto:)).
Se stai andando nella direzione del web, potresti prendere in considerazione HTML 5 e JavaScript con i controlli di terze parti. Ci sono quelli che si evolvono in questi giorni.
Buona fortuna.
La risposta a tutte le risposte: dipende
Quando sviluppi un'applicazione devi prendere alcune decisioni:
ecc. pp.
Quindi in questo punto puoi pensare all'astrazione. Incapsula la tua logica pura in diversi assembly e crea solo un layer UI in cima. In questo modo puoi usare diverse UI-Strategie.
Ma seriamente: quando vuoi sviluppare per Windows 8 assicurati che .NET 4.5 e Windows RT abbiano qualche differenza con .NET 4.0, che è eseguibile su XP, 7, Server ect. pp. Quindi spetta a te e ai tuoi clienti quale interfaccia utente svilupperai.
Ci sono troppi aspetti da considerare: i tuoi clienti hanno bisogno, i permessi che vuoi avere su un sistema, l'UX che vuoi dare alla tua app, ecc.
Le app Metro sono perfette per il tocco¹ e sono perfette per l'esperienza utente a singola applicazione a schermo intero. Puoi avere diversi validi motivi per fare un'app Metro:
Silverlight è ottimo per:
In entrambi i casi, il punto principale è che gli amministratori di sistema non devono occuparsi dell'installazione / mantenimento delle attività di sicurezza / aggiornamento relative alla tua app .
Le applicazioni WPF sono ottime per tutto il resto. Se hai bisogno di un'integrazione strong o di autorizzazioni aggiuntive e se sai che la tua app sarà utilizzata come app di business, a fianco di altri , in un lavoro quotidiano senza touch, vai per una normale app WPF .
Non dimenticare l'HTML. Se i tuoi clienti sono persone non tecniche che non saranno mai in grado (o vogliono) installare software aggiuntivo, aggiornarlo e mantenerlo senza l'aiuto di terze parti, o se i tuoi clienti utilizzano MacOS e non eseguono Windows su una macchina virtuale solo per l'uso la tua app, non andare affatto con Metro / Silverlight / WPF. Devi usare semplicemente HTML / XHTML. Può essere HTML 5 se si sa che il 95% degli utenti lo supporterà o una versione precedente se non lo è. Anche Flash è una soluzione, poiché è abbastanza popolare da essere installata sulla maggior parte dei computer.
¹ Non è perché sono app di Metro che sono automaticamente perfette per il tocco. Tu, in qualità di esperto di progettazione di interattori / sviluppatori, devi sapere come implementare in modo efficiente il tocco / multitouch sulla tua app. Niente è più fastidioso di un'app destinata a essere multitouch e che lo fa in modo totalmente errato (essendo allo stesso tempo inutilizzabile con mouse e / o tastiera, perché lo sviluppatore non si preoccupa che alcune persone utilizzino ancora quei dispositivi di input).
Non lo fai. Si scrive la logica del codice in modo tale che il livello della GUI possa essere facilmente sostituito con uno diverso: il codice per un'interfaccia e non un'implementazione. Come afferma @Max nel suo commento, questo non deve necessariamente essere nella lingua dell'applicazione finché si dispone di un modo per chiamarlo da tale applicazione.
Per quanto riguarda il framework, i WX widgets potrebbero essere utili come esempio di come gli altri hanno fatto una GUI che racchiude diverse implementazioni. Non sto suggerendo che questo è quello che dovresti usare.