Comment concevoir des applications de bureau d'entreprise pour Windows 8

Je pense avoir une compréhension des attentes du développement d'applications grand public pour Windows 8. Créez une nouvelle interface utilisateur basée sur Metro au-dessus de WinRT, déployez-la chez votre client via la Marketplace, et tout le monde y gagne. Semble assez simple. Malheureusement, je ne suis pas dans ce domaine.

Je travaille sur des applications métier internes pour une grande entreprise. Nous utilisons actuellement des technologies .NET telles que WPF et Silverlight afin de créer des interfaces utilisateur riches qui peuvent être facilement déployées pour nos utilisateurs via le Web ou ClickOnce. Les applications peuvent prendre en charge WinXP et Win7 sans trop de maux de tête, et nos développeurs peuvent utiliser XAML qui est une technologie d'interface utilisateur très solide.

Il semble que WPF et Silverlight aient un avenir douteux à ce stade, il est donc un peu inquiétant de continuer à investir dans ceux-ci. Mais une interface utilisateur Metro ne semble pas appropriée pour les applications d'entreprise, et l'API WinRT est assez limitante en ce qui concerne les tâches "typiques" que les applications d'entreprise doivent faire.

Comment dois-je concevoir mes applications basées sur XAML, actuellement en cours de déploiement sur WinXP et Win7, afin qu'elles soient supportables et évolutives sur Win8?

Supposons aux fins de cette question que les fonctionnalités fournies par HTML5 au-dessus d'ASP.NET ne sont pas adéquates pour les applications que je cherche à créer. Je comprends que je peux utiliser HTML5 pour certaines applications, mais j'essaie de comprendre ce que je dois faire lorsque cela ne suffit pas.

Edit # 1: Ceci est en réponse au commentaire de @Emmad Kareem. Je reconnais que Silverlight / WPF sont viables à court terme (2-5 ans). Cependant, les applications que nous produisons ont des durées de vie potentiellement très longues (10-20 ans et plus). La survie à long terme d'une technologie donnée nous préoccupe donc. En outre, nous craignons qu'il soit de plus en plus difficile de trouver des développeurs intéressés par le développement Silverlight / WPF si ces technologies sont considérées comme «mortes» par la communauté. Je veux juste comprendre mes options et prendre une décision les yeux ouverts.

Comment j'ai appris à arrêter de m'inquiéter et à aimer la pile MS

Vous pouvez toujours exécuter les applications VB6 sur Windows 8 . La rétro-compatibilité, bonne ou mauvaise, a toujours été une tendance dans l'écosystème de la SP. Vous ne devriez pas vous soucier de la survie de technologies comme WPF / Silveright, et même des formes de gain d'ailleurs.

D'un autre côté, vous devez accepter que pour un projet à long terme, vous n'aurez jamais la technologie la plus récente et la plus mignonne.

En fait, les questions que vous devez vous poser sur le choix d'une technologie sont:

• Mon équipe est-elle suffisamment à l'aise avec cette technologie pour être productive?
• Mon équipe est-elle heureuse d'utiliser cette technologie?
• Puis-je recruter des personnes pour cette technologie?

C'est la combinaison des réponses à ces questions qui devrait guider votre choix, et non les tendances forgées principalement pour des raisons marketing.

Pour en savoir plus sur cette thématique de technologie en constante évolution, vous devriez lire "Fire And Motion" de Joel Spolsky :

Les entreprises qui trébuchent sont celles qui passent trop de temps à lire les feuilles de thé pour déterminer l'orientation future de Microsoft. Les gens s'inquiètent pour .NET et décident de réécrire toute leur architecture pour .NET parce qu'ils pensent qu'ils doivent le faire. Microsoft vous tire dessus, et c'est juste un feu de couverture pour qu'ils puissent avancer et vous ne pouvez pas, car c'est ainsi que le jeu se joue, Bubby. Allez-vous soutenir Hailstorm? SAVON? RDF? Le soutenez-vous parce que vos clients en ont besoin ou parce que quelqu'un vous tire dessus et que vous avez le sentiment que vous devez répondre? Les équipes commerciales des grandes entreprises comprennent le feu de couverture.

Et cela a été écrit il y a près de dix ans.

Architecture et technologies

L'architecture et les technologies sont deux choses et choix à faire:

• Vous pouvez faire MVC avec des formes de victoire .
• Vous pouvez faire MVVM avec WPF / Silverlight .
• Vous pouvez faire MVC avec ASP.NET .
• Vous pouvez faire ce que vous voulez, y compris MVC et MVVM, avec WINRT à notre connaissance .
• Vous pouvez devenir fonctionnel avec F # . Pourquoi pas ? Il y a des domaines où cela aurait du sens.
• Vous pouvez les mélanger tous, avoir différents points d'entrée vers un système commun, puis vous moquer parce que cela devient trop compliqué , etc.

Vous pouvez utiliser des services, des ressources, des contrôles tiers, des ORM, etc. avec toutes ces technologies, et peut-être, ou peut-être pas, avec les suivantes.

Vous pouvez tordre et plier MVC de nombreuses façons avec toutes ces technologies: contraignantes ou non? code derrière la vue ou non? Contrôleur ou pas? ViewModel à chaque fois ou seulement en cas de besoin? Il existe de nombreuses façons de mettre en œuvre un modèle de conception, même dans le cadre d'une technologie spécifique.

Ce serait irréaliste de vous forcer à en faire partie sans une connaissance approfondie de votre projet et de votre équipe. Il ne serait basé que sur des préférences personnelles et aboutirait à une confrontation "Ma technologie est meilleure que la vôtre".

La seule chose qui peut être suggérée honnêtement et objectivement est d'utiliser les meilleures pratiques que vous pouvez appliquer pour créer une architecture qui résistera à l'épreuve du temps, et peut-être, vraiment peut-être sera portable ou réutilisée au moins dans des parties avec une future technologie inconnue . Et cette évolutivité / portabilité ne devrait même pas être l'objectif principal de votre architecture.

Le but principal de votre architecture et de la technologie choisie est de fournir à votre patron / client un produit qui réponde à ses exigences réalistes.

MVC (et son frère cadet MVVM) s'est avéré de plus en plus être une base pour une architecture robuste depuis 1979 dans l'arène des langages OOP et au-delà. Mais le choix de la technologie spécifique à utiliser dans un projet de 10 ans devrait rester votre décision.

Une chose que j'aborderai dans mon livre sur MVVM est de savoir comment tirer parti du modèle pour créer une application principale réutilisable. Vous devez créer une interface utilisateur native pour les différentes plates-formes que vous ciblez (que ce soit le Web, Silverlight, le téléphone, WPF ou WinRT). Mais pour la plupart, vous pouvez encapsuler la logique qui conduit cette interface utilisateur derrière un ViewModel.

Tous les services auxquels vous accédez doivent être placés derrière une interface (modèle de façade) plus ou moins portable entre les plates-formes. L'interface doit correspondre à votre API client à l'avant et se traduire à l'API du service encapsulé à l'arrière.

Cette stratégie vous aide à créer un cadre de base solide qui ne nécessite qu'une nouvelle interface utilisateur à superposer. Considérez-le comme votre modèle de vue étant les muscles, vos services font le squelette (et les organes). WPF / Silverlight / WinRT forment la peau.

En fait, une chose que je souligne très tôt dans mon livre est que MVVM n'est pas aussi nouveau qu'il n'y paraît. Dolphin Smalltalk avait un modèle similaire qu'ils appelaient MMVC (les deux M étaient Application Model et Domain Model). Le ViewModel que nous utilisons aujourd'hui n'est qu'une combinaison du modèle d'application et du contrôleur de MMVC. En fait, de nombreux développeurs trouvent qu'il est parfois judicieux de séparer le ViewModel en ses deux composants (le contrôleur étant utilisé pour la navigation et l'orchestration de plusieurs machines virtuelles afin que la machine virtuelle puisse parfaitement ignorer les autres composants).

Vous dites que XAML est solide mais dites ensuite que WPF a un avenir douteux. À moins que je manque quelque chose, WPF utilise XAML et je ne vois jamais les deux séparés. Y a-t-il des nouvelles qui me manquent à propos de WPF utilisant éventuellement une autre technologie de base, ou à propos de Microsoft envisageant même de construire encore une autre nouvelle façon de construire des interfaces utilisateur? En dehors de cela, je doute que WPF aille quelque part, mais ce ne serait pas la première fois que MS obsolète des cargaisons de notre code ...

Si vous avez besoin d'une application d'interface utilisateur riche et HTML5 ne le coupera pas, et que votre organisation est engagée dans Windows OS, je pense que WPF est le meilleur choix car c'est le dernier / le meilleur en ce moment, certainement sur les formulaires de victoire ...

Je pense que vous ne devriez pas trop vous concentrer sur les détails de mise en œuvre de vos applications. Si vous regardez une image plus grande, vous pouvez isoler vos dépendances technologiques. En isolant la dépendance par exemple à xaml / wpf / silverlight, vous vous assurez que vous pouvez remplacer le composant / la technologie ui par une technologie de nouvelle génération et ainsi garantir la continuité même dans 20 ans. Cela vous aidera également à découpler les composants de vos systèmes et, par conséquent, l'impact de devoir effectuer un tel remplacement. (En cela, je fais l'hypothèse que pour assurer la continuité, il est acceptable de bricoler une solution pour la faire fonctionner sur une plate-forme de prochaine génération)

Une autre façon d'assurer l'isolement de ces dépendances technologiques consiste à activer la virtualisation. Si vous concevez vos applications de manière à pouvoir les exécuter dans une VM, vous pourrez le faire dans 20 ans!