Quelle technologie pour un projet plus important?

Question

Je planifie un plus grand projet, donc je considère quelques options technologiques.

Le projet utilisera la conception d'architecture à 3 niveaux. La couche de présentation sera ASP.NET mais il pourrait s'agir d'une autre technologie. Cela n'a pas d'importance pour le moment.

Mes questions sont les suivantes:

1. Pour le serveur aplication dois-je utiliser un service Windows ou tout simplement une application normale?
2. Que dois-je utiliser pour la communication entre la couche de présentation et la couche de domaine? Je voulais utiliser .NET Remoting mais j'ai lu que Remoting fait partie de WCF. En fait, je ne suis pas si familier avec WCF c'est pourquoi je demande. Alors. Remoting .NET ou WCF?

Je vous remercie de tout soupçon

Answer 1

Pour le serveur d'applications, je suppose que les services Windows seraient votre meilleur choix, même si c'est plus de travail qu'il ne devrait l'être. Si vous n'avez pas besoin de déployer maintenant, vous pouvez également jeter un oeil à "Dublin" - un add-on pour .NET 4.0 qui augmentera le WAS (Windows Process Activation Server) avec des outils de gestion et d'autres choses. Avec cela, vous pourriez être en mesure d'héberger et de gérer vos services WCF d'une manière agréable et très puissante.Comme pour # 2 - je recommanderais sans hésiter WCF - c'est la plate-forme de choix pour la communication dans les systèmes distribués, et avec sa configurabilité et sa flexibilité, il peut gérer à peu près n'importe quelle tâche que vous voulez lui lancer. De la communication très rapide sur machine (NetNamedPipeBinding) à la gestion de la communication via Windows Azure ServiceBus - un service de relais "dans le cloud" - c'est que puissant! Vous ne pouvez pas vous tromper avec WCF - il peut gérer tous vos besoins de communication, je dirais. Ne perdez pas votre temps à apprendre des technologies obsolètes comme .NET Remoting ou ASMX ou WSE services Web (juste mes 0,02 $ pour cette discussion).

Marc

Answer 2

1. Les services sont la voie à suivre; un utilisateur n'a pas besoin d'être connecté pour être en cours d'exécution; ils sont bien équipés pour l'administration à distance; ils sont également mieux adaptés pour être surveillés pour la santé

2. Remoting peut être utilisé via WCF; WCF agrège de nombreuses plates-formes de communication différentes et fournit des configurations faciles à exploiter. À mon avis, apprendre la WCF serait la meilleure façon d'y aller, mais si vous êtes familier avec Remoting et que vous êtes certain qu'il couvre tous vos besoins, alors ça devrait aller aussi.

Answer 3

Réponse 2)

WCF est une nouvelle bibliothèque qui combine différents mécanismes de communication en utilisant une API unique. Le choix du mécanisme (ou de la liaison dans le langage WCF) dépend de vos besoins. Pour les performances, vous pouvez essayer NetTcpBinding, ou si vous voulez qu'il soit accessible via HTTP, vous pouvez essayer BasicHttpBinding. Plus d'infos sur WCF from MSDN.

Answer 4

En fait, le choix de la couche de présentation est important.

Si vous effectuez des installations côté client, l'utilisation de WCF pour la communication entre la couche de domaine et le client prend tout son sens. Toutefois, si vous écrivez une interface utilisateur pure-ASP.NET, le fait de disposer d'une application Web appelant des services Web susceptibles d'être hébergés localement a de sérieuses implications en termes de performances (messagerie et sérialisation/désérialisation).

En pensant à un projet sur lequel j'ai travaillé récemment, dans lequel nous devions prendre en charge les deux, nous avons hébergé des services dans le même domaine d'application que l'interface Web ASP.NET. L'utilisateur a effectué la plus grande partie de l'interaction via l'interface Web, et une petite application cliente, qui s'est adressée au niveau intermédiaire via les services Web, a été lancée lorsqu'une interaction client plus riche était requise.

Answer 5

Si vous demandez ce genre de questions, il y a encore beaucoup dans la définition de votre projet, vous ne savez pas. Pas vraiment un problème, puisque même si vous le faisiez, la plupart changeraient probablement avant que vous ayez terminé. En outre, quelle que soit la technologie que vous choisirez, vous rencontrerez des lacunes importantes pour lesquelles vous n'étiez pas préparés, car personne ne craignait que vous rencontriez un problème.

Ne choisissez pas la technologie maintenant. Commencez avec quelque chose de petit et livrable que vous comprenez bien, et construisez-le. Développer en plus de cela dans de petites pièces maniables. Montrez souvent ce que vous avez à votre «client» et recevez des commentaires.

Le véritable tour est de l'architecturer d'une manière qui vous permet de changer facilement de direction lorsque de nouvelles informations deviennent disponibles. C'est ici que je vous recommande de passer le plus clair de votre temps à trouver une architecture extensible et à créer des tests pour vérifier que tout continue de fonctionner à mesure que vous avancez. À mesure que le projet prendra de l'ampleur, les technologies dont vous aurez besoin deviendront beaucoup plus claires.

Answer 6

WCF est la seule technologie à utiliser pour les communications. Notez que même le bus de service .NET qui fait partie d'Azure utilise WCF. Comme pour les autres "choix":

• WSE est obsolète il a été remplacé par WCF. Il est construit sur
• services Web ASMX, que Microsoft now considers to be "legacy technology"
• Remoting a été dépréciée en faveur de la WCF

Il n'y a pas d'autre choix intelligent, à moins que, pour une raison quelconque, vous êtes coincé en utilisant .NET 2.0 ou .NET 1.1.