Redondance, fiabilité et tolérance aux pannes en C# - où chercher des exemples?

Question

Je veux apprendre à créer vraiment applications robustes dans .net - ceux qui sont tolérants aux pannes et sont capables de résister à des situations inattendues. Où puis-je trouver de la documentation/des conseils sur ce sujet? Jusqu'à présent, je n'ai pas beaucoup de chance.

Answer 1

Je connais au moins quelques ressources. Tout d'abord, il y a un article très utile sur MSDN intitulé Keep Your Code Running with the Reliability Features of the .NET Framework.

Chris Brumme avait également un post on hosting lorsque les fonctions de fiabilité étaient en cours de conception. Cela peut fournir des informations de base utiles

Les termes de recherche que vous pouvez trouver utiles incluent "Haute disponibilité" "CER" et "Contrained Execution Regions".

Bonne chance! Le code vraiment disponible est assez difficile. :)

Answer 2

Si vous êtes à la recherche d'un point de vue de la mise en œuvre du logiciel, il peut être intéressant de regarder dans Design by Contract (DbC)

Selon this source, les avantages de la conception par contrat sont les suivants:

• Une meilleure compréhension la méthode orientée objet et plus généralement la construction logicielle.
• Une approche systématique pour construire des systèmes orientés objet sans bug.
• Un cadre efficace pour le débogage, les tests et, plus généralement, l'assurance qualité.
• L'invention concerne un procédé de documentation de composants logiciels.
• Meilleure compréhension et contrôle du mécanisme d'héritage.
• Une technique pour traiter des cas anormaux, conduisant à une construction de langage sûre et efficace pour la gestion des exceptions.

En outre, je préconiserais de regarder dans une approche Test Driven Development (TDD), ce qui devrait aider à chasser une conception plus robuste.

Answer 3

Personnellement, j'ai trouvé que l'article de Stephen Toub était la meilleure source concernant les régions d'exécution contraintes: Using the Reliability Features of the .NET Framework. Et à la fin, CER est le pain et le beurre de tout code tolérant aux pannes, donc cet article contient à peu près tout ce que vous devez savoir, expliqué de manière claire et concise. Cela étant dit, vous pourriez plutôt choisir de privilégier un design plus radical où vous aurez immédiatement recours à la destruction du domaine d'application (ou dépendez de ce modèle lorsque le CLR est hébergé). Vous pourriez regarder le modèle de cloison étanche par exemple (et peut-être le reactive manifesto si vous êtes intéressé par ce modèle et que vous faites face à des flux de données complexes). Cela étant dit, l'approche «laissez tomber» peut se retourner contre vous si vous ne pouvez pas complètement récupérer après cela, comme demonstrated by Ariane V.