Come progettare le applicazioni desktop aziendali per Windows 8

Penso di avere una comprensione delle aspettative di sviluppo di applicazioni consumer per Windows 8. Crea una nuova interfaccia utente basata su Metro in cima a WinRT, distribuiscila al tuo cliente tramite il Marketplace e tutti vincono. Sembra abbastanza semplice. Sfortunatamente, non sono in quel settore.

Lavoro su applicazioni interne line-of-business per una grande impresa. Attualmente utilizziamo tecnologie .NET come WPF e Silverlight per creare interfacce utente complete che possono essere facilmente distribuite ai nostri utenti tramite il Web o ClickOnce. Le applicazioni possono supportare WinXP e Win7 senza troppi mal di testa, ei nostri sviluppatori possono usare XAML che è una tecnologia UI molto solida.

Sembra che WPF e Silverlight abbiano futuri discutibili a questo punto, quindi è un po 'preoccupante continuare a investire in quelli. Ma un'interfaccia utente Metro non sembra appropriata per le applicazioni aziendali e l'API WinRT è piuttosto limitante per quanto riguarda le cose "tipiche" che le applicazioni aziendali devono fare.

Come dovrei progettare le mie applicazioni basate su XAML, attualmente distribuite su WinXP e Win7, in modo che siano sostenibili ed evolvibili su Win8?

Supponiamo ai fini di questa domanda che le funzionalità fornite da HTML5 su ASP.NET non siano adeguate per le applicazioni che sto cercando di creare. Capisco che posso usare HTML5 per alcune applicazioni, ma sto cercando di capire cosa dovrei fare quando non è abbastanza.

Modifica n. 1: questo è in risposta al commento di @Emmad Kareem. Concordo sul fatto che Silverlight / WPF siano praticabili a breve termine (2-5 anni). Tuttavia, le applicazioni che produciamo hanno una durata potenzialmente molto lunga (10-20 + anni). Quindi la sopravvivenza a lungo termine per una data tecnologia è una preoccupazione per noi. Inoltre, temiamo che sarà sempre più difficile trovare sviluppatori interessati allo sviluppo di Silverlight / WPF se tali tecnologie sono considerate "morte" dalla comunità. Voglio solo capire le mie opzioni e prendere una decisione con gli occhi aperti.

Come ho imparato a smettere di preoccuparmi e ad amare lo stack MS

Puoi comunque eseguire le app VB6 su Windows 8 . La retrocompatibilità nel bene e nel male è sempre stata una tendenza nell'ecosistema MS. Non dovresti preoccuparti della sopravvivenza di tecnologie come WPF / Silveright e persino di winform per quella materia.

D'altra parte, devi accettare che per un progetto a lungo termine, non avrai mai la tecnologia più recente e più carina.

In effetti le domande che dovresti porti sulla scelta di una tecnologia sono:

• Il mio team è abbastanza a suo agio con quella tecnologia per essere produttivo?
• Il mio team è felice di usare quella tecnologia?
• Posso reclutare persone per quella tecnologia?

Questa è la combinazione delle risposte a queste domande che dovrebbero guidare la tua scelta, e non le tendenze forgiate principalmente per ragioni di marketing.

Per ulteriori informazioni su questa tematica della tecnologia in continua evoluzione, dovresti leggere "Fire And Motion" di Joel Spolsky :

Le aziende che inciampano sono quelle che passano troppo tempo a leggere le foglie di tè per capire la direzione futura di Microsoft. Le persone si preoccupano di .NET e decidono di riscrivere l'intera architettura per .NET perché pensano di doverlo fare. Microsoft ti sta sparando, ed è solo copertura del fuoco in modo che possano andare avanti e tu no, perché è così che si gioca, Bubby. Sosterrai Hailstorm? SAPONE? RDF? Lo stai supportando perché i tuoi clienti ne hanno bisogno o perché qualcuno ti sta sparando e senti di dover rispondere? I team di vendita delle grandi aziende comprendono il fuoco di copertura.

E questo è stato scritto quasi dieci anni fa.

Architettura e tecnologie

Architettura e tecnologie sono due cose e scelte separate da fare:

• Puoi fare MVC con winforms .
• Puoi fare MVVM con WPF / Silverlight .
• Puoi eseguire MVC con ASP.NET .
• Puoi fare quello che vuoi, inclusi MVC e MVVM, con WINRT per quanto ne sappiamo .
• Puoi andare funzionale con F # . Perchè no ? Ci sono domini in cui avrebbe senso.
• Puoi mescolarli tutti, avere diversi punti di ingresso in un sistema comune, quindi essere deriso perché diventa troppo complicato , ecc.

È possibile utilizzare servizi, risorse, controlli di terze parti, ORM, ecc. Con tutte queste tecnologie e forse, o forse no, con le prossime.

Puoi torcere e piegare MVC in molti modi con tutte quelle tecnologie: Binding o no? codice dietro la vista o no? Controller o no? ViewModel ogni volta o solo quando necessario? Esistono molti modi per implementare un modello di progettazione, anche nell'ambito di una tecnologia specifica.

Sarebbe irrealistico costringerti a entrare in uno di essi senza una conoscenza avanzata del tuo progetto e del tuo team. Si baserebbe solo sulle preferenze personali e finirebbe in uno scontro "la mia tecnologia è migliore della tua".

L'unica cosa che può essere onestamente e obiettivamente suggerita è quella di utilizzare le migliori pratiche che è possibile applicare per creare un'architettura che resisterà alla prova del tempo, e forse, forse davvero sarà portatile o riutilizzato almeno in parti con una futura tecnologia sconosciuta . E quella aggiornabilità / portabilità non dovrebbe nemmeno essere lo scopo principale della tua architettura.

Lo scopo principale della tua architettura e della tecnologia scelta è quello di fornire un prodotto al tuo capo / cliente che soddisfi i suoi requisiti realistici.

MVC (ed è il fratello minore MVVM) si è dimostrato sempre più una base per un'architettura robusta dal 1979 nell'arena dei linguaggi OOP e oltre. Ma scegliere quale tecnologia specifica dovrebbe essere utilizzata in un progetto lungo 10 anni dovrebbe rimanere una tua decisione.

Una cosa che affronterò nel mio libro su MVVM è come sfruttare il modello per creare un'applicazione core riutilizzabile. Dovresti creare un'interfaccia utente nativa per le varie piattaforme di destinazione (che si tratti di Web, Silverlight, telefono, WPF o WinRT). Ma per la maggior parte, è possibile incapsulare la logica che guida l'interfaccia utente dietro un ViewModel.

Tutti i servizi a cui accedi devono essere racchiusi in un'interfaccia (modello di facciata) più o meno portatile tra le piattaforme. L'interfaccia dovrebbe essere mappata all'API client sul lato anteriore e tradurla all'API del servizio spostato sul retro.

Questa strategia ti aiuta a creare un solido framework di base che richiede solo una nuova interfaccia utente da sovrapporre. Pensa che il tuo modello di vista sia costituito dai muscoli, i tuoi servizi creano lo scheletro (e gli organi). WPF / Silverlight / WinRT formano la pelle.

In effetti, una cosa che sottolineo molto presto nel mio libro è che MVVM non è così nuovo come sembra. Dolphin Smalltalk aveva un modello simile a quello che chiamavano MMVC (le due M erano il modello di applicazione e il modello di dominio). Il ViewModel che usiamo oggi è solo una combinazione del modello applicativo e del controller di MMVC. In effetti molti sviluppatori stanno scoprendo che a volte separare ViewModel nei suoi due componenti ha senso (il controller viene utilizzato per la navigazione e l'orchestrazione di più VM in modo che la VM possa rimanere beata inconsapevolmente di altri componenti).

Dici che XAML è solido ma poi dici che WPF ha un futuro discutibile. A meno che non mi manchi qualcosa, WPF usa XAML e non vedo mai i due essere separati. Ci sono alcune notizie che mi mancano sul fatto che WPF possa usare qualche altra tecnologia di base o che Microsoft stia forse considerando la possibilità di creare un altro nuovo modo per costruire le interfacce utente? A parte questo, dubito che WPF vada da nessuna parte, ma non sarebbe la prima volta che MS carica obsoleti caricamenti del nostro codice ...

Se hai bisogno di una ricca app UI e HTML5 non la taglierà, e la tua organizzazione è impegnata nel sistema operativo Windows, penso che WPF sia la scelta migliore in quanto è l'ultima / la più grande in questo momento, sicuramente rispetto alle winforms ...

La mia opinione su questo è che non dovresti concentrarti troppo sui dettagli di implementazione delle tue applicazioni. Se guardi un quadro più ampio, puoi isolare le tue dipendenze tecnologiche. Isolando la dipendenza, ad esempio, da xaml / wpf / silverlight, si garantisce di poter sostituire il componente / tecnologia dell'interfaccia utente con una tecnologia di prossima generazione e quindi garantire la continuità anche tra 20 anni. Ciò aiuterà anche a disaccoppiare i componenti del sistema e quindi l'impatto di dover eseguire tale sostituzione. (In questo presuppongo che per fornire continuità sia giusto armeggiare con una soluzione per farlo funzionare su una piattaforma di prossima generazione)

Un altro modo per fornire isolamento da queste dipendenze tecnologiche è consentire la virtualizzazione. Se crei le tue applicazioni in modo tale da poterle eseguire in un VM, sarai in grado di farlo in 20 anni!