ASP.Net ou WPF (C #)? [fermé]

31

Notre équipe est divisée à ce sujet et je voulais obtenir des opinions de tiers.

Nous construisons une application et ne pouvons pas décider si nous voulons utiliser l'application de bureau .Net WPF avec un serveur WCF ou une application Web ASP.Net utilisant jQuery. J'ai pensé poser la question ici, avec quelques spécifications, et voir quels seraient les avantages / inconvénients de l'utilisation de chaque côté. J'ai mon propre favori et je me sens biaisé.

Idéalement, nous voulons créer la version initiale du logiciel aussi vite que possible, puis ralentir et prendre le temps de créer les fonctionnalités / composants supplémentaires que nous voulons plus tard. Nous voulons avant tout que le logiciel soit rapide. Les utilisateurs parcourent les enregistrements toute la journée et les retards dans le chargement des enregistrements ou les écrans rafraîchissants tuent leur productivité.

Détails de la demande:

  • J'évalue environ 100 écrans différents pour la version initiale, avec des plans pour beaucoup d'écrans supplémentaires ajoutés plus tard après la sortie initiale.
  • Nous cherchons à utiliser la communication bidirectionnelle pour les systèmes de rappel et d'événement
  • Doit actuellement prendre en charge environ 100 utilisateurs, bien qu'on nous ait dit de permettre une croissance jusqu'à 500 utilisateurs
  • Nous avons plusieurs emplacements

Éléments à considérer (peut-être pas initialement dans certains cas mais dans les versions futures):

  • Possibilité d'ajouter des composants supplémentaires après la version initiale (il y en a beaucoup ... peut-être fonctionner ici que l'application initiale)
  • Navigation au clavier
  • La performance est un must
  • Vitesse de production jusqu'à la version initiale
  • Frais généraux réduits
  • Support futur
  • Intégration softphone / scanner

Nos développeurs:

  • Nous avons 1 programmeur qui a appris WPF au cours des derniers mois et qui a suggéré d'utiliser WPF pour cela.
  • Nous avons un 2ème programmeur qui connaît bien ASP.Net et qui pourrait aider avec le projet à l'avenir, bien qu'il n'y travaillera pas beaucoup jusqu'à la version initiale car son temps est consacré à la maintenance de notre logiciel actuel.
  • Il y a moi, qui a travaillé avec les deux et qui est à l'aise dans les deux
  • Nous avons une entreprise extérieure qui gère le projet et c'est une entreprise ASP.Net.
  • Nous prévoyons d'embaucher 1 ou 2 autres personnes, mais nous devons d'abord savoir dans quelle direction nous allons

Environnement:

  • Les utilisateurs généraux sont sur le serveur Windows 2003 avec les services Terminal Server. Ils se connectent à l'aide de clients légers WYSE via une connexion RDP. Le personnel administratif a son propre PC avec XP ou supérieur. Les utilisateurs sont autorisés à spécifier leur propre résolution bien qu'ils se limitent à utiliser IE comme navigateur Web.
  • D'autres emplacements se connectent à notre réseau via une connexion MPLS

Sur cette base, que choisiriez-vous et pourquoi?

Rachel
la source
J'adore tous les votes, mais j'aimerais vraiment entendre plus d'opinions à ce sujet :)
Rachel
3
que faites-vous qui nécessite 100 écrans au départ ?
Steven A. Lowe
Cette estimation comprend de nombreux écrans partiels. Par exemple, l'écran principal est décomposé en un tas de "morceaux" qui peuvent être ajoutés / supprimés / déplacés / redimensionnés selon les besoins de l'utilisateur. Chacun a son propre ensemble de données, sa propre vue d'édition et son propre ensemble d'actions qui peuvent être effectuées. Je les compte comme séparés au lieu d'un seul écran car chacun est très différent.
Rachel
Utilisez .NET MVC 3, JQuery et HTML5
Oliver Picton
1
Salut @kmote, nous avons fini par aller avec WPF et étions très satisfaits de la décision. Cela a permis beaucoup plus de flexibilité dans la construction de l'interface utilisateur, et j'ai trouvé qu'il était assez rapide à construire par rapport à une solution basée sur le Web. Malheureusement, le projet a été annulé après un an en raison d'autres priorités, mais si on me présentait à nouveau le même choix, je prendrais la même décision.
Rachel

Réponses:

17

Cela me ressemble certainement à une application WPF, avec beaucoup d'interaction utilisateur et potentiellement interagissant avec du matériel. Vous pouvez fournir l'application via Click-Once, le déploiement n'est donc généralement pas un problème. Votre application WPF peut accéder à un service WCF et fournir les données sous forme binaire afin que les performances soient excellentes. Je commencerais à lire sur WPF et à me familiariser avec lui dès que possible.

Walter
la source
+1 De plus, avec TOUS ces écrans, vous voudrez probablement créer autant de réutilisation que possible dans votre application (code et interface graphique)
Jon Onstott
+1 J'imagine qu'avec "l'intégration Softphone / Scanner" requise, je suppose que le seul moyen est WPF. Ou peut-être qu'il est possible d'utiliser Silverlight
Jiew Meng
15

Réponse marginale lunatique: les deux. Obtenez la bonne couche de service, il est facile d'avoir un client lourd qui fait tout (WPF) et un client Web rapide pour faire les choses les plus courantes (ASP.NET). Laisse la porte ouverte au client mobile, etc., sur la route.

Wyatt Barnett
la source
C'est ce que nous pensons faire .... Application client WPF pour la plupart des utilisations avec une version Web légère pour les rapports ou un accès limité.
Rachel
2
+1 à cela, écrivez les tripes de non-présentation dans le langage .NET que vous êtes à l'aise - puis utilisez le meilleur outil pour chaque tâche de présentation (par exemple: l'application Web utilise l'interface ASP.NET pour cette application, le bureau utilise WPF / Winforms / etc).
heretik
Au départ, les utilisateurs peuvent trouver ASP.NET «assez bon», surtout si cela signifie obtenir plus de morceaux de l'application plus tôt.
JeffO
8

Si vous n'avez qu'un seul programmeur qui a appris WPF et que vous envisagez de faire passer votre équipe à WPF, alors pourquoi ne pas utiliser Silverlight à la place? Vous bénéficiez de nombreux avantages de WPF tout en conservant la possibilité de quitter votre projet en tant qu'application Web. Puisque vous cherchez à avoir un grand projet modulaire, il serait logique d'utiliser PRISM avec WPF ou Silverlight pour simplifier MVVM.

Mon équipe a récemment fait le choix d'utiliser Silverlight sur asp.net. Ce fut un choix fantastique pour nous. Au départ, nous n'avions qu'un seul développeur qui connaissait le Silverlight. Ensuite, nous avons tous suivi un cours de formation d'une semaine qui était pour la plupart inutile, mais au moins nous avons mouillé les pieds. En fin de compte, nous avons dû embaucher deux entrepreneurs pour nous aider à créer la majeure partie de notre cadre d'interface utilisateur. La majorité de notre équipe n'a toujours pas confiance en ses compétences Silverlight. Moi-même, le premier membre de l'équipe connaissant Silverlight, et les deux sous-traitants sont les principaux responsables du développement de SL. Après cela, nous avons deux membres back-end dédiés. Je dirais qu'il nous a fallu environ 2 mois après avoir pris la décision de passer à Silverlight pour que nous ayons vraiment mis en place quelque chose de concret. cependant, nous avons maintenant un produit merveilleux qui ressemble beaucoup à une application côté client qui s'exécute à l'intérieur d'un navigateur Web et qui n'est installée sur aucune machine localement. Le développement a duré moins d'un an au total et nous sommes presque prêts à publier ou à proposer la première version.

Quelques points à considérer:

  • WPF ou silverlight, selon votre choix, vos développeurs devront en apprendre beaucoup.

  • Silverlight peut manquer de navigateur si nécessaire. Si vous faites cela, il est assez facile de le configurer de sorte que si vous déployez une nouvelle version, le programme SL installé hors du navigateur se mettra automatiquement à jour.

  • Silverlight n'inclut pas tous les contrôles dont dispose WPF.

Ma dernière remarque est que si vous souhaitez produire du code aussi rapidement que possible, il est évident que vous devriez utiliser ASP.NET. Mon principal scrupule avec ASP est qu'à moins de discipliner votre équipe, il est facile pour un projet ASP.NET de devenir encombré et désordonné. Si vous pensez que vous serez en mesure de faire face aux frais généraux initiaux liés à la mise à niveau des technologies, Silverlight ou WPF vous offrira de nombreuses possibilités merveilleuses.

Kavet Kerek
la source
Nous sommes dans une situation très similaire et j'ai trouvé intéressant d'entendre votre histoire, merci. Je considérerai Silverlight, bien que jusqu'à présent je n'ai utilisé que WPF. Si nous partons avec WPF, nous avions prévu de faire notre section Reporting dans Silverlight, alors j'avais prévu de l'apprendre finalement
Rachel
Je suis en train de convertir (lire la réécriture) une application ASP.NET dans Silverlight - essentiellement parce que ASP.NET ne s'adapte pas à ce que nous voulons qu'il fasse.
ChrisF
1
Juste pour info: rappelez-vous que Silverlight ne sera pas un produit majeur de la SEP, et dans certains cas, les gens disent qu'il peut être mécontent. Je suis d'accord qu'il serait bon d'envisager, il suffit d'ajouter ces informations à votre liste de contre possibles.
Paige Watson
1
Je considérerais fortement WPF plutôt que Silverlight pour ce type d'application. WPF peut être facilement déployé en tant que XBAP (application de navigateur xaml), généralement avec seulement quelques modifications de code dans le fichier de configuration. WPF a tout ce que Silverlight fait et plus encore, plus WPF obtient beaucoup plus de support. Le seul inconvénient est que, alors que Silverlight peut potentiellement être déployé sur plusieurs systèmes d'exploitation (même Linux avec le projet Moonlight), WPF requiert .Net sur le client, donc strictement Windows.
Morgan Herlocker
2
Je ne sais pas si Silverlight sera interrompu, mais quelque chose de similaire est l'article Mashable Microsoft passe de Silverlight à HTML5 . Personnellement, je considérerai sérieusement Pure Web Apps si c'est possible sur des plugins de bureau ou propriétaires si possible
Jiew Meng
7

Cette partie est assez préoccupante:

Les utilisateurs généraux sont sur le serveur Windows 2003 avec les services Terminal Server. Ils se connectent à l'aide de clients légers WYSE via une connexion RDP. Le personnel administratif a son propre PC avec XP ou supérieur. Les utilisateurs sont autorisés à spécifier leur propre résolution bien qu'ils se limitent à utiliser IE comme navigateur Web.

WPF n'est pas génial sur les connexions client Bureau à distance / Thin. Les animations ne seront pas fluides et toutes les images complexes (même les dégradés) ralentiront la réponse de l'interface utilisateur à une analyse. Le personnel administratif avec des machines XP rétro typiques aura également très probablement des problèmes de performances avec des applications WPF complexes (en raison de petites quantités de RAM et de mauvais GPU).

Si vous optez pour la route WPF pour des graphiques riches, préparez-vous aux hacks de performance de dernière minute lorsque vous découvrez que les machines cibles ont dix ans. Restez fidèle aux écrans statiques et utilisez .NET 4.0 car les performances WPF se sont considérablement améliorées depuis la version 3.5.

Ed Andersen
la source
Merci ... c'est en fait une grande préoccupation pour moi, bien que jusqu'à présent, il semble que nous pouvons réduire les graphiques si l'utilisateur est sur une connexion RDP et que les tests se sont bien déroulés.
Rachel
2

Techniquement, je pense que la combinaison WPF / WCF est la meilleure solution.

Cependant, je ne suis pas convaincu que votre programmeur WPF existant ait vraiment l'expérience de ce projet. WPF est tout à fait un changement dans la programmation des processus de pensée de la programmation Winform et vous devrez donc réfléchir longuement à ce que vous avez vraiment des compétences suffisantes dans l'équipe pour fournir cette route.

Michael Shaw
la source
1
+1 `` Apprendre pendant quelques mois '' pourrait signifier quelque chose - préparez-vous à une courbe d'apprentissage abrupte.
Kirk Broadhurst
1

Intéressant. Cela semble étonnamment familier à une application que nous venons de démarrer dans mon entreprise (intégration de téléphones SIP et de scanners et tout).

Nous avons choisi silverlight en mettant l'accent sur SOA afin qu'une application WPF puisse être créée par la suite si le besoin s'en fait sentir.

Possibilité d'ajouter des composants supplémentaires après la version initiale (il y en a beaucoup ... peut-être fonctionner ici que l'application initiale)

Nous utilisons MEF dans la couche service et construisons des points d'extension (interfaces de plugin décrivant certains points où nous planifions l'extensibilité ou l'intégration avec d'autres systèmes)

Navigation au clavier

Pas de problème.

La performance est un must

Quel genre de performance? Performances perçues (snappy-ness) ou performances de calcul des nombres? Ce dernier pourrait être un problème avec une application web / silverlight. Pour les premiers, notre application passe par de nombreux enregistrements, comme le vôtre, mais nous sommes en mesure de les prédire et de pré-récupérer les enregistrements pendant que les utilisateurs travaillent sur les enregistrements actuels. Les temps de «chargement» sont nuls pour cette section de notre application.

Vitesse de production jusqu'à la version initiale

Dépend de la compétence. Mais en réalité, tout le monde veut toujours arriver sur le marché le plus rapidement possible, c'est donc un non-argument.

Frais généraux réduits

Comme la vitesse de production, c'est aussi un non argument et cela va se résumer à des pratiques de conception et de codage. Si vous parlez de maintenance matérielle, vous voudrez peut-être opter pour une application cloud.

Support futur

Je ne sais pas ce que cela signifie.

Intégration softphone / scanner

Silverlight 4 permet maintenant d'accéder à la webcam / au micro (nous espérons faire de la vidéoconférence inter-applications ainsi que de l'intégration SIP), donc si vous utilisez un serveur téléphonique, vous pouvez en écrire un vous-même. Je n'en connais aucun, mais cela pourrait aider.

Sinon, vous devrez peut-être faire un piratage laid (ne faites plus référence aux articles, désolé) ou vous n'avez pas d'autre choix que d'avoir une application WPF qui peut interagir avec le système de fichiers. SL4 peut sortir du navigateur, mais il ne peut accéder qu'à certaines parties du système de fichiers. Aucun d'entre eux ne sera probablement les pièces dont vous avez besoin pour interagir avec un téléphone SIP.

Vous voulez dire, scanner de documents? Je ne suis pas sûre de ça. Nous utilisons des scanners manuels / codes à barres, et ils fonctionnent comme n'importe quel autre périphérique d'entrée et ne posent aucun problème.

Steven Evers
la source
1

avez-vous besoin d'une application très réactive pour les gens à utiliser toute la journée? utiliser WPF; vous trouverez également plus facile de réutiliser les composants GUI dans WPF sur ASP / MVC (IMHO)

oui, jquery et al sont excellents, silverlight est cool, mais les applications de bureau sont toujours plus efficaces

pour le back-end, WCF va bien

Steven A. Lowe
la source
0

Je vais devoir vous recommander d'utiliser WCF pour votre couche de service en raison de l'évolutivité et de la sécurité. Pour la couche de présentation, vous pouvez utiliser Silverlight ou ASP.NET, Silverlight est comme Flash, mais il est difficile à comprendre et à avoir une courbe d'apprentissage élevée au début, surtout lorsque vous travaillez avec des données. ASP.NET est plus facile à utiliser, mais vous aurez besoin de beaucoup de réglages et de javascript pour l'utiliser efficacement.

Victor Gil
la source
1
Le plan est d'avoir une couche de service WCF indépendamment de ce que nous choisissons de faire pour la couche d'interface utilisateur. Nous essayons de décider si nous voulons WPF / Desktop ou ASP / Web pour l'application cliente. Même si nous optons pour une application de bureau, il y a de fortes chances que nous ayons un portail Web pour accéder à un sous-ensemble d'éléments tels que les rapports.
Rachel