Comment gérez-vous votre application lorsque la base de données est hors ligne ?

Question

Prenez une application .Net Winforms.mélangez une connexion réseau sans fil irrégulière, mélangez avec quelques utilisateurs qui aiment simplement retirer la prise bleue de temps en temps et pour faire bonne mesure, ajoutez un administrateur système qui décide de redémarrer le serveur SQL sans avertissement de temps en temps juste pour garder tout le monde connecté leurs orteils.

Quelles sont les suggestions et stratégies pour gérer ce type de scénario en ce qui concerne :

• Gestion des erreurs - Par exemple, enveloppez-vous chaque appel au serveur avec un essai / capture ou comptez-vous sur une forme de gestion des erreurs génériques pour gérer cela?Si oui, à quoi ressemble-t-il?

• Gestion des applications - Par exemple, désactivez-vous l'application et ne permettez-vous pas aux utilisateurs d'interagir avec lui jusqu'à ce qu'une connexion soit à nouveau détectée?Que feriez-vous?

Answer 1

La réponse dépend du type de votre candidature.Il existe des applications qui peuvent fonctionner hors ligne – Microsoft Outlook par exemple.Ces applications ne traitent pas les exceptions de connectivité comme critiques, elles peuvent enregistrer votre travail localement et le synchroniser ultérieurement.D'autres applications telles que les jeux en ligne traiteront les problèmes de communication comme une exception critique et se fermeront si la connexion est perdue.

En ce qui concerne la gestion des erreurs, je pense que vous devriez contrôler les exceptions sur toutes les couches plutôt que de vous fier à un morceau de code général de gestion des exceptions.Votre couche métier doit comprendre ce qui s'est passé sur la couche inférieure (couche d'accès aux données dans notre cas) et réagir en conséquence.La perte de connexion ne doit pas être traitée comme exception inattendue à mon avis.Pour les bonnes pratiques de gestion des exceptions, je recommande de jeter un oeil à Bloc d’application de gestion des exceptions.

En ce qui concerne le comportement de l'application, vous devriez vous répondre à la question suivante "Mon application a-t-elle une valeur commerciale pour le client à l'état déconnecté?" Dans de nombreux cas, il serait avantageux de mettre fin à l'utilisateur de pouvoir poursuivre son travail à l'état déconnecté.Cependant, un tel comportement est extrêmement difficile à mettre en œuvre.

Spécialement pour votre scénario développé par Microsoft Bloc d'application de l'agent de service déconnecté

Answer 2

Je n'ai pas touché à WinForms et .NET depuis des années maintenant, je ne peux donc pas vous donner de détails techniques, mais il y a une réponse plus claire :

Avant tout, ne liez pas les données de votre formulaire directement à une base de données.

Créez une couche de données/modèle distincte à laquelle vous liez vos widgets de formulaire.

À partir de là, plusieurs options s’offrent à vous en fonction du niveau de stabilité et de disponibilité que vous devez offrir.

L'une des solutions les plus simples ici serait probablement d'activer/désactiver simplement les parties de l'application qui doivent interagir avec une base de données en fonction de l'état de la connexion.

Le niveau de protection suivant inclurait la mise en cache locale de la partie du modèle de données et, pendant que la connexion à la base de données est interrompue, l'utilisation du cache local pour afficher et désactiver toutes les fonctions nécessitant une connexion explicite à la base de données.

La chose la plus délicate (qui peut également offrir l'expérience la plus stable à l'utilisateur final) est probablement de répliquer la base de données localement et d'utiliser une sorte de schéma de synchronisation pour garder votre copie de la base de données synchronisée avec la base de données distante.

Answer 3

C'est peut-être un peu aussi beaucoup de support pour le scénario hors ligne, mais avez-vous pensé au "Cadre de synchronisation Microsoft" ?Le framework comprend les « Services de synchronisation pour ADO.NET 2.0 », qui permettent à votre application d'accéder à une instance locale de SQL Server CE.Cela peut facilement être synchronisé avec un serveur SQL central via diverses méthodes.

Ce framework gère le scénario hors ligne permanent et, comme je l'ai dit, il n'est peut-être pas approprié à vos besoins spécifiques, mais il offrira à votre application un solide support hors ligne.

Answer 4

Nous avons ceci dans notre Main() méthode qui piège toutes les exceptions non gérées...

Application.ThreadException += new 
System.Threading.ThreadExceptionEventHandler(UnhandledExceptionCatcher);

Thread.GetDomain().UnhandledException += new 
UnhandledExceptionEventHandler(Application_UnhandledException);

et puis Application_UnhandledException et UnhandledExceptionCatcher afficher des messages conviviaux.

De plus, l'application envoie ensuite par courrier électronique des données telles que la trace de la pile aux développeurs, ce qui peut être très utile.

Cela dépend bien sûr de l'application, mais pour le type d'échecs que vous décrivez, je fermerais l'application.

Answer 5

Dans notre application, nous donnons à l'utilisateur la possibilité de se connecter à un autre serveur. Par exemple, si la connexion à la base de données échoue, une boîte de dialogue s'affiche indiquant que le serveur n'est pas disponible et il peut saisir une autre adresse IP pour essayer.

Answer 6

Utilisez quelque chose comme SQLite pour stocker des données hors ligne jusqu'à ce qu'une connexion soit disponible.

Mise à jour:Je crois que SQLite est le back-end pour Google Engrenages, qui, d'après ma compréhension, fait ce que vous recherchez dans les applications Web...même si je ne sais pas s'il peut être utilisé dans un contexte non Web.