Dossier Développement : Le facteur Azure

Ce faisant, il est facile de tomber dans le piège consistant à copier le code de votre première application et à le modifier pour créer la deuxième. Je considère la possibilité du copier/coller/modifier en vue de la réutilisation comme une opportunité de créer une meilleure bibliothèque. Vous devez discerner les parties communes de celles qui ne le sont pas. Cette opération est parfois aisée. Dans d’autres cas, comme avec les rôles Worker, vous devrez faire appel à vos tours de magie et utiliser Action<>, Func<>, des requêtes LINQ et des méthodes d’extension en vue de créer la bibliothèque souhaitée. Dans cet article, je vais prendre l’exemple d’une application Azure et montrer comment créer des algorithmes réutilisables fonctionnant avec tous vos rôles Worker.

L’exemple est une version simplifiée d’une application que j’utilise pour le suivi de ma bibliothèque de liens Web. Un rôle Web Azure affiche la bibliothèque de liens. Il est possible de voir une description du site et l’URL, et il suffit de cliquer sur le lien pour ouvrir le site concerné dans une nouvelle fenêtre. Bien évidemment, il est possible d’ajouter des liens à la bibliothèque. Un problème que je rencontre régulièrement est le fait que certains liens Web anciens ne fonctionnent plus. J’ai toujours des liens obsolètes dans mes favoris. Je ne prends pas le temps de visiter régulièrement tous les liens et de supprimer ceux devenus inopérants. Azure possède une architecture qui permet d’éviter plus facilement ce problème.

Un rôle Worker Azure peut essayer de télécharger périodiquement tous les liens. Il marque les liens qui ne fonctionnent pas comme potentiellement défectueux. La classe de rôle Worker se présente comme suit. Il s’agit du code idiomatique que vous rencontrerez dans de nombreuses applications Azure. La méthode Start() est une boucle infinie qui reste en sommeil pendant un certain temps, puis effectue certaines actions, avant de repasser en sommeil. Le travail exécuté est écrit dans un style très impératif. Au final, ce code inclut des pratiques aboutissant à des programmes problématiques en termes de maintenance et d’amélioration. Premièrement, la logique réelle pour cette application est mélangée avec du code passe-partout qui pourrait être commun à n’importe quel rôle Worker que vous créez. Deuxièmement, l’approche met trop l’accent sur la manière dont un rôle Worker doit être codé lorsque vous souhaitez que votre code montre les actions exécutées par ce rôle. Enfin, vous savez que lorsque vous devez créer un nouveau rôle Worker, vous allez copier ce code dans votre nouveau rôle Worker, puis le modifier en fonction des besoins du nouveau rôle.