Qu'est-ce qu'une bonne architecture pour un service et un serveur?

Question

Je construis une application qui permet aux utilisateurs d'exécuter certaines commandes sur un ordinateur en les envoyant par courrier électronique. Le serveur surveillera (tirera) un ou plusieurs comptes de courrier électronique et commencera une session de communication. Une certaine authentification est également impliquée. J'utilise les dernières et meilleures technologies .net.

Je pense à exposer le serveur en tant que service, mais je ne peux pas avoir une interface graphique pour permettre à l'utilisateur de configurer des choses comme les mots de passe et les comptes de messagerie. Comment puis-je les séparer? Deuxièmement, les commandes seront pluginables et devraient fournir leur propre interface graphique. Comment puis-je l'incorporer? Le processus serveur doit pouvoir utiliser la fonctionnalité de commande et le processus d'interface graphique doit permettre la personnalisation.

Answer 1

J'ai utilisé WCF, qui est la technologie actuelle de Microsoft pour la mise en œuvre de services Web et/ou SOA. Vous créez un client de bureau ou une page Web qui effectue des appels au service WCF. Le (s) service (s) WCF serait votre composant de serveur, et le client de bureau ou la page Web serait votre interface utilisateur.

Answer 2

Ce n'est principalement pas une question de comment faire le service lui-même. Et le protocole de communication n'est pas le problème principal - avec WCF, vous pouvez exposer vos méthodes d'application via un spectre de protocoles. C'est simplement une question de configuration de l'application.

La principale question ici est de savoir comment vous voulez mettre en œuvre l'interface graphique. Si votre application est un service Windows normal, elle ne peut pas avoir d'interface graphique intégrée. Juste parce que le service ne devrait pas l'avoir. Vous aurez donc besoin d'une application graphique séparée. Options:

1. GUI est une application autonome .NET qui communique d'une manière ou d'une autre avec votre service. Disons via WCF. Dans ce cas, les plugins doivent également être implémentés en deux parties: plugin pour le service et plugin pour l'interface graphique. Je pense que ce serait trop complexe à soutenir.

2. Modification du 1er variant. Le service et l'interface graphique sont emballés dans un exécutable. Il regarde dans quel mode il a démarré (service ou standalone) et surveille le courrier ou montre l'interface graphique. Puisque c'est une application, la configuration est également la même. Donc, vous aurez un registre unique pour les plugins. Je suppose que, en mode interface graphique, l'application recherchera le service démarré et le configurera. Inconvénient: l'interface graphique peut être exécutée uniquement localement. Vous faites une sorte de GUI "transférable" - l'interface graphique envoie le GUI au client simple, qui le montre. Dans ce cas, vous disposez d'un emplacement pour tout le code de l'application (service et interface graphique), mais il est exécuté en partie en service, en partie dans le logiciel client. Mais vous avez également besoin d'un tel logiciel client universel. En pensant un peu plus à propos de la variante 3, nous voyons que la solution existe déjà - ce sont les technologies web. Il serait plus simple de mettre en œuvre votre service en tant que partie d'un site Web. Et GUI serait une autre partie. Si vous n'êtes pas familier avec HTML et Javascript, vous pouvez implémenter une interface graphique en utilisant Silverlight.

3. En fait, vous pouvez héberger ASP.NET directement dans votre service. Here is the good explanation. Mais j'ai peur que cela ajoute une complexité inutile