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


15

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.


Je dois me présenter à une réunion, mais j'ai une réponse pour vous :)
Michael Brown

2
Pourquoi changeriez-vous le WPF / Silverlight que vous connaissez déjà? Votre déclaration "WPF et Silverlight ont un avenir douteux", eh bien, Microsoft ne laissera pas tomber cette technologie pendant la nuit. La poursuite de sa croissance n'est pas une préoccupation réelle si vous disposez aujourd'hui de suffisamment de fonctionnalités. En bref, vous devez avoir une raison technique solide pour envisager une architecture totalement nouvelle. Une partie de la peur est que les gens perdent leur expérience pour une autre technologie. Je ne peux pas leur en vouloir.
NoChance

3
Vous voulez qu'une pile technologique unique dure plus de 10 ans? Pourquoi ne pas vous concentrer sur une bonne architecture et de bons principes de conception pour permettre à votre système d'évoluer dans le temps pour utiliser les technologies appropriées? Jetez un œil à Visual Studio - il existe depuis 1995 et a évolué au fil du temps. Par exemple, Visual Studio 2010 a ajouté une actualisation d'interface utilisateur majeure qui comprenait l'utilisation de WPF et d'autres modifications architecturales pour ajouter des points d'extensibilité. Vous ne pouvez pas contrôler quelles technologies ou quels paradigmes vont devenir importants l'année prochaine, et encore moins dans le délai que vous regardez.
Thomas Owens

5
Qu'est-ce qui vous fait penser que vous utiliserez Windows dans 20 ans?
JonnyBoats

1
@JonnyBoats: Parce que nous l'étions il y a 20 ans ? Ou parce que leur principal concurrent est basé sur un système encore plus ancien ? Il n'y a aucun moyen de prédire la chute ou la survie d'une technologie spécifique.
Matthieu

Réponses:


15

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 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.


Je suis totalement d'accord avec cette réponse. Vous ne pouvez jamais savoir avec certitude. Mais il existe plusieurs technologies qui pourraient répondre aux questions que vous posez, et je dois encore choisir parmi elles.
RationalGeek

@jkohlhepp: ajout d'un paragraphe sur l'architecture et les technologies. Je maintiens mon point de vue qu'il est impossible de recommander objectivement une technologie sur l'autre ou une architecture sur l'autre.
Matthieu

Votre position est qu'il n'y a pas de base objective pour comparer les architectures / technologies? N'est-ce pas là tout l'objet de la discipline architecturale? Je suis d'accord que tout dépend des exigences de mes patrons. L'une de ces exigences est la longévité maximale au moindre coût, d'où cette question.
RationalGeek

@jkohlhepp: La discipline de l'architecture logicielle à mon humble avis est comme la médecine. Vous acquérez de l'expérience pour trouver le bon traitement pour une maladie spécifique. Il existe parfois différentes façons de le faire, et il peut être dangereux d'essayer de guérir tout le monde de la même manière avec le même traitement. Si vous avez une équipe efficace de programmeurs expérimentés dans WPF et Silverlight, respectez-la et conservez votre architecture existante. Si vous devez le changer, ne le changez pas uniquement parce qu'il existe de nouvelles façons de faire, que vous faites déjà efficacement, commercialisées par Microsoft.
Matthieu

Je peux embarquer avec ce Matthieu. Merci pour les réponses réfléchies.
RationalGeek

1

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).


Je suis totalement d'accord sur la disposition des différentes parties de l'application. Et je suis également tout à fait d'accord pour dire que vous devez rendre votre interface utilisateur aussi stupide que possible, car les technologies d'interface ont tendance à tourner un peu. Mais, même après avoir créé ces couches, vous avez encore une estimation à faire sur les technologies qui seront meilleures / moins chères à long terme.
RationalGeek

Si je devais deviner ... alors que HTML5 est la nouvelle rage de nos jours, Microsoft va continuer à prendre en charge XAML car ils le contrôlent. Ils ont tiré leur leçon de Java (ils envisageaient à l'origine d'utiliser Java comme premier langage .NET lorsque Sun est devenu litigieux). Construire votre application sur des principes solides (interface utilisateur déclarative soutenue par un riche modèle d'objet portable) devrait vous aider à surmonter la tempête. J'ai même des exemples de faire MVVM en Javascript (consultez js knockout).
Michael Brown

0

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 ...


La direction que j'ai entendu de MS a laissé entendre que WPF n'a pas beaucoup d'avenir à long terme. Mais ils n'ont rien annoncé. Je m'attends à ce qu'ils le mettent en "mode maintenance" comme ils l'ont fait avec LINQ To SQL.
RationalGeek

WPF est déprécié dans Windows 8 (en ce que vous obtenez soudainement un retour au "mode bureau" et hors de l'expérience Metro immersive). Cependant, vous pouvez créer des applications Metro avec XAML. Ce sont des technologies complètement distinctes.
Domenic

Euh, non, ce n'est pas obsolète, car le bureau est toujours un élément clé de l'expérience. Quant aux «technologies complètement séparées» - vraiment? Sûrement beaucoup plus proche des variations sur un thème comme c'est déjà le cas avec WPF vs Silverlight (par opposition à, disons, l'utilisation de XAML pour le workflow ...)
Murph

0

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!


D'un certain sens, je peux comprendre cette perspective. Cependant, je ne dois choisir une technologie d'interface utilisateur à un moment donné, et en fonction de ce choix , il faudra remplacer / mettre à jour tôt ou tard. Je voudrais faire un choix qui se traduit par une longévité maximale.
RationalGeek

Selon le site du cycle de vie, Silverlight5 sera pris en charge jusqu'en octobre 2021 support.microsoft.com/lifecycle/?p1=16278 Donc, quoi qu'il arrive à la feuille de route, c'est toujours un choix solide.
Carlo Kuip
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.