En ASP.NET, je note habituellement les exceptions côté serveur. Dans les formulaires Windows, je peux soit noter les exceptions côté serveur ou écrire dans un fichier journal sur le client. Silverlight semble se situer quelque part entre les deux.
Je voulais savoir ce que tout le monde fait pour gérer leurs exceptions Silverlight et j'étais curieux de savoir si des meilleures pratiques ont déjà émergé pour cela.
Pour un enregistrement réel que vous pourriez stocker et suivre, vous devrez le faire sur le serveur, car vous ne pouvez pas garantir que quoi que ce soit sur le client sera persistant.
Je suggérerais d'exposer une méthode "LogEvent(..)" sur un service web côté serveur (peut-être en avez-vous déjà un) qui ferait ensuite le même type de journalisation que vous faites en ASP.net
Voici une vidéo sur les appels de base de services web en Silverlight si vous ne l'avez pas encore fait http://silverlight.net/learn/learnvideo.aspx?video=66723
Je ne suis pas sûr des meilleures pratiques en matière de journalisation, ma première idée serait d'adopter les meilleures pratiques pour la journalisation dans un service web sur le serveur et de les exposer au client.
J'espère que cela vous aide!
Je dirais que Silverlight s'intègre beaucoup mieux à la partie côté ASP.NET du modèle. Vous avez un serveur qui sert la page web. Un objet (application Silverlight) sur la page envoie une requête au service de données pour récupérer les données et les afficher.
Tout l'accès aux données se fait côté serveur et peu importe si les données sont utilisées pour créer des pages ASP.NET sur le serveur ou envoyées brutes au RIA pour affichage. Je consigne toutes les défaillances du service de données côté serveur (le journal des événements fonctionne bien) et n'autorise aucune exception à passer à WCF. Lorsque le client ne reçoit pas les données attendues (il reçoit une collection nulle ou quelque chose de similaire), il affiche un message d'erreur générique d'accès aux données à l'utilisateur. Nous devrons peut-être bientôt étendre cela pour transmettre un peu plus d'informations (faire la distinction entre l'accès refusé/base de données manquante/défaillance de l'infrastructure/erreur interne, etc.), mais nous n'avons pas prévu de transmettre les messages d'erreur d'exception au client.
Quant au côté client, parfois nous pouvons nous retrouver dans une situation où l'appel asynchrone prend trop de temps -- c'est simplement un autre message. Pour les exceptions générales du code client (généralement, des bugs dans notre code), je transmets simplement l'exception au navigateur pour l'afficher de la même manière que toute exception de script.
Utilisez le Stockage isolé disponible pour l'application Silverlight. Vous devriez y stocker vos journaux.
Ensuite, vous pouvez développer un mécanisme pour envoyer le journal de l'utilisateur à un service web tel que le service de rapport de bogues Windows.
Jetez également un œil au nouveau Pack d'intégration Silverlight pour Enterprise Library de Microsoft patterns & practices. Il offre un support pour le journal des exceptions vers le stockage isolé ou les services distants et est configurable via des politiques dans une configuration externe ou de façon programmatique. Le journal en lot et la nouvelle tentative automatique (en cas de scénarios de connectivité occasionnelle) sont également pris en charge.
Cela dépend beaucoup du type d'application que vous développez.
si c'est une architecture basée sur mvc / mvp alors votre modèle, ou du moins la plupart de celui-ci, sera sur le serveur, et c'est là que la plupart de vos exceptions seront probablement lancées, donc vous pouvez les journaliser là et choisir d'afficher un message à l'utilisateur ou non.
pour les exceptions provenant du client, vous voudrez peut-être en connaître les détails alors renvoyez-les simplement.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
