2009-10-24 5 views
1

Je construis une application WinForms où j'en aurai besoin pour travailler "localement" (comme Microsoft Word, en enregistrant et en ouvrant des fichiers depuis le système de fichiers) et également dans un environnement multi-utilisateurs (communication avec un serveur du réseau, via TCP/IP).WCF pour l'application en mode local et en réseau - plus question sur le profil client .NET

En termes d'architecture, je pense à ces couches logiques:

  • Présentation (Windows Forms)
  • service
  • Data Access

Mon plan est de faire de la " Service "couche un service WCF. Ainsi, lorsque l'application fonctionne en mode "local", j'hébergerais le service WCF dans le processus Presentation (exécutable). La présentation serait un hôte de service ET un client en même temps. Il accéderait à la couche de service en utilisant un proxy WCF, en pointant sur "localhost". Lorsque l'application est dans un environnement réseau, je souhaite héberger le même service WCF dans un processus "Service Windows/NT" sur un autre ordinateur, et Presentation communique avec ce dernier en utilisant le même proxy WCF que dans mode local.

Autrement dit, pour la présentation, je n'aurais qu'une seule API.

En théorie, cela semble bon. Cependant, j'aimerais connaître votre opinion sur tout cela. Est-ce une mauvaise pratique d'utiliser WCF de cette manière, ayant le serveur et le client dans le même processus? Pouvez-vous voir une alternative/meilleure façon de faire cela? Une autre question (peut-être sans rapport) est: puis-je héberger et consommer un service WCF dans le même exécutable Windows Forms si je marque l'installation du profil client .NET Framework?

J'apprécie vos commentaires :)

Répondre

1

Je dirais que ce n'est pas une mauvaise pratique du tout pour héberger le serveur et le client dans le même processus - il appelle la communication inter-processus! :-)

Pour le scénario local, j'utiliserais la liaison NetNamedPipe - rapide comme l'enfer, pour la communication "sur machine" seulement. Pour le scénario LAN, il suffit de passer à NetTcpBinding - très rapide et efficace également.

Devrait fonctionner comme un charme.

Selon this page sur le .NET Framework Client Profile, à peu près tous WCF devrait être pris en charge sur le profil du client:

WCF fonctionnalités prises en charge par le Framework .Net client Profil

Le fonctionnalités suivantes Windows Communication Foundation sont pris en charge par .NET Framework client Profile:

* All of WCF is supported except for Cardspace and web hosting. 
* Remoting TCP/IP channels are supported. 
* Asmx (Web Services) are not supported. 

Marc