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