Relation UI et Application

Question

J'ai lu beaucoup d'articles sur l'interface utilisateur, la logique d'entreprise, la WCF, l'IoC, mais il me manque encore une chose. Je construis une application winforms et une application console. l'application Console est le cerveau. Maintenant, dans toute l'architecture client-serveur, le client "connaît" le serveur, lui envoie une requête et obtient la réponse. Ma question est la suivante:

1) Comment l'application console peut-elle afficher un message à l'utilisateur s'il ne connaît pas l'existence de l'interface utilisateur? L'interface utilisateur doit-elle vérifier et regrouper les messages toutes les x msec? Est-ce une bonne approche? 2) dans le cas où les formulaires d'assurance-chômage devraient afficher un prix de référence, par exemple le cours de l'action qui change tout le temps? devrait-il demander le prix du téléscripteur à partir de l'application de console toutes les 200msec? ou enregistrer une fonction de rappel dans l'application console pour que l'application console puisse l'appeler? Cependant, ne fait-il pas l'interface utilisateur dans un serveur maintenant?

3) Que se passe-t-il si je veux ajouter une capacité de terminal à mon application (par exemple, telnet cli), comment dois-je le concevoir? le serveur telnet en tant que client et mon application console en tant que serveur? Y at-il un design qui peut m'aider à y parvenir? TAXI? J'ai demandé à beaucoup de gens et il semble que personne ne l'utilise ... est-ce vrai?

Merci, Eyal

Answer 1

Votre programme doit être conçu de manière à pouvoir remplacer une interface utilisateur par une autre. Le programme devrait pouvoir avoir la fonction logique indépendamment de l'interface que l'utilisateur voit. Jetez un oeil aux modèles MVC et Observer. Une bonne mesure de votre programme passe par les interfaces mises à la disposition de l'utilisateur [appels API, interface graphique basée sur la console, interface basée sur la console, interface réseau, web]. Je ne veux pas dire que vous devriez recentrer l'intention de l'application doit être sur le rendre très flexible avec l'interface. Je suggère que votre interface ne doit rien avoir à faire avec la logique et la banque de données de votre application.

Stock ticker: Avoir un modèle d'observateur qui diffuse un nouvel événement toutes les 200ms, ou sur les changements. La vue ticker serait un abonné de ces événements.

Answer 2

Pourquoi ne pas créer le "cerveau" comme une bibliothèque? Une interface WinForms et une application console sont toutes les deux des interfaces utilisateur et doivent être séparées de la logique. Cela permet un accès plus facile aux fonctions et vous pouvez également vous abonner à des événements.

Answer 3

Vous devriez éviter l'architecture que vous envisagez. Obtenir deux processus distincts pour travailler ensemble est compliqué. Le système d'exploitation met en place un grand mur entre les processus pour s'assurer qu'un processus qui ne se comporte pas correctement ne peut pas déstabiliser l'autre. Les processus ont chacun leur propre vision de la mémoire, Windows (et .NET en particulier), il est très difficile pour les processus de partager de la mémoire.

Vous devrez établir un canal de communication entre les processus pour les faire fonctionner ensemble. Un tuyau ou une douille est le choix habituel, le modèle mental ici est celui des machines qui se parlent sur un réseau. Cela peut être très gênant, vous auriez tous les inconvénients d'une application web, aucun des avantages d'un client WinForms ou d'une application en mode console. Il est également très peu fiable, l'échec d'un processus est difficile à diagnostiquer, à signaler et à récupérer par l'autre application. Je suis sûr que vous avez vu ce qui peut mal se passer lors de l'utilisation de votre navigateur Internet.

Vous pouvez obtenir ce que vous voulez d'une application. La classe System.Threading.Thread vous donne l'équivalent moral de votre application en mode console.Obtenir l'interface utilisateur pour afficher les messages du thread de cerveau est assez simple avec la classe BackgroundWorker ou la méthode Control.Begin/Invoke(). Seulement "assez" btw, obtenir le fil interop droit est toujours un effort.

Il existe deux façons d'implémenter la mise à jour de l'action boursière. La poussée par rapport à l'approche par traction. L'approche push permet au thread d'arrière-plan de notifier activement le thread d'interface utilisateur qu'une mise à jour est disponible. BackgroundWorker.ReportProgress ou Control.Begin/Invoke pour faire cela. À 200 msec mises à jour, ce n'est pas un problème.

À des taux comme celui-ci, le modèle de traction fonctionnera tout aussi bien. Vous utiliseriez un temporisateur dans l'interface utilisateur pour obtenir une méthode à exécuter périodiquement. Il pourrait lire la valeur d'une propriété partagée dans la méthode Tick du timer. Vous devrez utiliser l'instruction lock dans le thread d'arrière-plan et dans la méthode Tick pour vous assurer que la valeur ne peut pas changer au moment où le thread de l'interface utilisateur lit la valeur. Vous devriez privilégier le modèle pull lorsque la valeur peut changer très rapidement, en poussant à une vitesse qui mettra le thread de l'interface utilisateur à genoux lorsque le temps nécessaire pour mettre à jour l'interface utilisateur est plus long que la période entre les mises à jour du thread d'arrière-plan . Le fil de l'interface utilisateur va prendre du retard et ne va pas à ses fonctions normales. Une interface gelée est le diagnostic, OOM est le résultat final. 200 ms ne devrait pas être un problème, sauf si vous êtes très chic ou bâclé avec vos mises à jour de l'interface utilisateur, la poussée devrait fonctionner.

Je vais devoir rejoindre la ligue d'amis que vous avez consultés sur les serveurs Telnet. Je ne sais pas quel problème ils résolvent, ils sont l'équivalent en 1990 d'un serveur web quand tout le monde utilisait un terminal à écran vert pour parler à un ordinateur. Cela s'applique peut-être à la nécessité de connecter une application en mode console séparée à une application d'interface utilisateur. Vous n'utilisez pas telnet pour le faire, une socket est un canal générique. .NET Remoting ou, mieux, WCF est la couche qui se trouve au-dessus de ce canal pour éviter d'avoir à faire face aux complications de compression de données ou de paramètres de méthode à travers un tuyau d'octets. Poursuivre que si vous êtes déjà complètement dans une solution multi-processus déjà. Vous ne devriez pas être pour une application ticker boursier, personne ne se soucie de quelle façon ils cocher s'il n'y a personne pour les regarder. Chute d'arbre dans la forêt, peut-être.