Come architettare le applicazioni desktop aziendali per Windows 8

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

Puoi ancora eseguire app VB6 su windows 8 . La retro-compatibilità per buona o cattiva è sempre stata una tendenza nell'ecosistema MS. Non dovresti preoccuparti della sopravvivenza di tecnologie come WPF / Silveright e persino winforms per questo.

D'altro canto, devi accettare che per un progetto a lungo termine, non avrai mai la tecnologia più recente e precisa.

In effetti le domande da porsi riguardo la scelta di una tecnologia sono:

• La mia squadra è abbastanza a suo agio con quella tecnologia per essere produttiva?
• La mia squadra è felice di usare quella tecnologia?
• Posso reclutare persone con questa 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 :

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire.

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 fare MVC con ASP.NET .
• Puoi fare quello che vuoi, incluso MVC e MVVM, con WINRT fino a sappiamo .
• Puoi andare in funzione con F # . Perché no? Ci sono domini in cui avrebbe senso.
• Puoi mescolarli tutti, per avere diversi punti di accesso a un sistema comune, quindi essere deriso perché diventa troppo complicato , ecc.

Puoi utilizzare servizi, risorse, controlli di terze parti, ORM, ecc. con tutte queste tecnologie, e forse, o forse no, con quelle successive.

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

Sarebbe irrealistico costringerti a uno di loro senza una conoscenza avanzata del tuo progetto e della tua squadra. Si baserebbe solo su preferenze personali e finirebbe con lo showdown "La mia tecnologia è migliore del tuo".

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

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

MVC (ed è il fratello minore MVVM) ha dimostrato sempre più di essere 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 di 10 anni dovrebbe rimanere la tua decisione.

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

Tutti i servizi a cui accedi devono essere racchiusi dietro un'interfaccia (pattern di facciata) che è più o meno portabile tra le piattaforme. L'interfaccia deve essere associata all'API del client sul lato anteriore e tradurla nell'API del servizio spostato sul retro.

Questa strategia ti aiuta a creare un solido framework di base che richiede solo una nuova interfaccia utente per essere sovrapposto su di esso. Consideralo come il tuo modello di vista come i muscoli, i tuoi servizi rendono 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 uno schema simile che chiamavano MMVC (i due M erano modello di applicazione e modello di dominio). Il ViewModel che usiamo oggi è solo una combinazione di Application Model e 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 beatamente inconsapevole di altri componenti).

Dici che XAML è solido, ma poi dici che WPF ha un futuro discutibile. A meno che mi manchi qualcosa, WPF usa XAML e non vedo i due mai separati. C'è qualche notizia che mi manca di WPF forse usando qualche altra tecnologia di base, o di Microsoft forse anche considerando di costruire ancora un altro nuovo modo di costruire le UI? Al di fuori di questo, dubito che WPF stia andando da qualche parte, ma non sarebbe la prima volta che MS ha un carico di navi obsoleto del nostro codice ...

Se hai bisogno di una ricca applicazione per l'interfaccia utente e HTML5 non la tagli, e tu sei impegnato con il sistema operativo Windows, penso che WPF sia la scelta migliore in quanto è l'ultima / la più grande in questo momento, sicuramente su Winforms .. .

La mia opinione è che non dovresti concentrarti troppo sui dettagli di implementazione delle tue applicazioni. Se si guarda un'immagine più grande, è possibile isolare le dipendenze della tecnologia. Per isolatin la dipendenza su es. xaml / wpf / silverlight ti garantisce di poter sostituire il componente ui / la tecnologia con una tecnologia di nuova generazione e quindi di garantire la continuità anche in 20 anni. Questo aiuterà anche a disaccoppiare i componenti del sistema e quindi l'impatto di dover eseguire tale sostituzione. (In questo suppongo che per fornire continuità sia giusto armeggiare con una soluzione per farlo funzionare su una piattaforma di nuova generazione)

Un altro modo per fornire isolamento da queste dipendenze tecnologiche è abilitare la virtualizzazione. Se costruisci le tue applicazioni in modo tale da essere in grado di eseguirle in un VM, sarai in grado di farlo in 20 anni!