Design l'application multi-niveau à utiliser la barre de progression

Question

J'ai une application multi niveaux dans c # qui est censé effectuer des tâches sur une base de données (Si la première utilisation, nous pouvons créer la base de données et le remplir avec des données). Lorsque j'ai conçu d'abord l'application que je ne tenait pas compte d'un éventuel contrôle de barre de progression, encore moins de rapports sur les progrès de toute sorte. Comment puis-je modifier la conception de l'application pour pouvoir rendre compte des opérations de base de données progressent à la couche d'interface utilisateur? Y at-il une solution là-bas qui est réutilisable et ne me force pas à modifier toutes mes fonctions pour prendre des entrées supplémentaires pour le reporting?

Answer 1

Non

. Selon la taille de votre application est, vous avez beaucoup de travail devant vous.

Pour les rapports d'étape au travail, vous avez besoin du code qui effectue le travail à des événements soulèvent quand une unité de travail est terminée. Que les besoins de l'événement à traiter les indicateurs de la couche d'interface utilisateur et de progrès mises à jour.

Un bon endroit pour commencer serait de regarder dans BackgroundWorker (il y a un exemple sur MSDN ici - http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx ). Une fois que vous êtes familier avec le BackgroundWorker, vous devriez être dans une meilleure position pour décider quels changements vous devez apporter à votre application.

Answer 2

Comme Greg dit, il y a beaucoup de travail à venir. Cependant, il existe de nombreuses façons d'aborder le problème, et le meilleur pour vous dépend de ce que l'information contextuelle passe vers le bas du client aux couches application / base de données déjà. Par exemple, si un identifiant symbolique ou d'une transaction session est transmis du client à l'application dans le cours normal de l'exécution d'une requête / transaction ou une référence d'accusé de réception repassé en mode asynchrone de l'application au client, puis pour les requêtes / transactions pour lesquelles des rapports d'étape était nécessaire, vous pourriez avoir l'application mise à jour d'une table d'état que le client pourrait interroger. Cela pourrait réduire la quantité de re-travail requis. Fondamentalement, vous devez considérer le « middleware » déjà en place et voir si cela peut être mis à profit pour les transactions corrèlent entre les différents niveaux.

Answer 3

Vous pouvez modifier le code du serveur pour qu'il mette à des informations de progression à la fin du serveur (sans changer les signatures de fonction), puis une méthode distincte qui peut interroger ces informations séparément.

Cela vous permettra de soutenir la mise à niveau de progrès sans avoir aucun impact sur vos appels existants au serveur, il suffit d'ajouter un nouveau thread d'arrière-plan sur la vérification de l'interface utilisateur pour les informations de progression mis à jour pendant une tâche longue en cours d'exécution est en cours.

Edit: Je suppose que la même approche fonctionnerait pour les tâches qui se déroulent dans le client. Mais encore, une classe d'indicateur de progression statique pourrait être utilisé ici.