Alain Metge

Le titre de cet article résume relativement bien mon état d'esprit du moment.

En Janvier de cette année, Microsoft propose un framework technique appelé "Enterprise Library", ou plus simplement Entlib, qui se veut un framework proposant, sous une forme unique et homogéne, de regrouper plusieurs patterns proposés initialement sous le nom de "Application Block". Ces patterns n'ont pas été repris tel quel mais leurs finalités restent les mêmes.

Les Application Block sont encore disponibles sur le site de microsoft. (Il est à noter l'effort fait part Microsoft à ce niveau car, jusqu'à .NET, Microsoft nous vendait de la techno mais restait plutôt sobre sur la façon de l'utiliser.) Ces patterns, qui sont libres de droits d'utilisation et dont le code source est fourni, nous ont servis de base pour le développement de notre framework technique. Des adaptations ont été nécessaires mais le gain de développement est évident.

Lorsqu'en Janvier, Microsoft propose Entreprise Library, j'ai tout de suite était intéressé par la démarche. Le code source est toujours fourni, une communauté importante s'est instaurée trés rapidement proposant des exemples, des tutoriaux, des extensions... Le source est bien documenté, facile à maintenir et à reprendre.

De plus, une équipe lui est dédiée chez Avanade, garantissant un certain niveau de support.

L'idée de base était de ré-intégrer entlib dans notre framework, nous l'avons fait relativement rapidement. Cela fonctionne, c'est séduisant. Il nous faut revoir certaines spécificités mais rien de bien important.

Cependant, avec l'arrivée du framework .NET 2.0, beaucoup de questions se posent. En particulier, le module de la gestion des configurations (paramètrages) qui est la pierre angulaire de tout le framework (tous les autres modules l'utilise) fait doublon avec celui du 2.0. Dans les 2 cas, on peut lire et écrire, des providers sont disponibles...

De la même façon, le module d'accès aux données est redondant (Factory, chaîne de connexion dans le fichier de config...)

Cela laisse à réfléchir, même dans l'équipe d'Avanade.

En gros, ma réflexion du moment est :
- Pour la migration de notre framework vers .NET 2.0, il est urgent d'attendre ce qu'ils vont proposer pour Entlib 2.0. En espérant qu'il se mettront en conformité avec le framework .NET.
- Pour notre framework actuel, qui fonctionne bien avec les Applications Blocks, ce n'est pas la peine de migrer quoi que ce soit.

Donc pour résumé, Enterprise Library 1.0 arrive trop tard.

Ce n'est pas un problème en soi, mais cela commence à m'inquiéter car Microsoft brouille un peu les cartes en proposant les Entreprises Library en même temps que le framework 2.0. Deux frameworks "officiels" complémentaires mais non compatibles.

Dèjà que les annonces (whidbey, yukon, indigo, avalon, longhorn...) se succédent à un train d'enfer et que les choix seront difficiles, j'avoue que ce type d'annonce me perturbe un peu, particulièrement au niveau de la pérennité de ce framework.

Je maitrise pas encore le bignou. L'article est à cette adresse.

Je me décide enfin à participer à ce (grand) fait de société qu'est le blog.

Je suis responsable de la cellule architecture logicielle aux Autoroutes du Sud de la France. Nous avons choisi d'évoluer, il y a maintenant plus de 2 ans vers la technologie .NET. C'est dans ce contexte que je souhaiterai partager mes connaissances (et profiter des votres) en me mettant à blogger.

J'espére que je vais arriver à m'y tenir.

On va bien voir.

Le framework Enterprise Library, fourni par Microsoft et Avanade, intègre un outil permettant de gérer les diffèrents paramètres de configuration, ce qui rend leur mise à jour beaucoup plus conviviable.

Mais l'utilisation de cet outil a un revers, il est nécessaire de générer pour chaque classe de paramètres une classe "designer" permettant de la gérer dans l'outil.

Si on veut utiliser cet outil pour gérer vos propres paramètres applicatifs, il faut générer 2 classes support, en plus de votre classe. La procédure est expliquée sur le blog de hisham baz.

L'extension que je propose permet de gérer vos paramètres applicatifs avec le designer sans création de code supplémentaire. L'astuce est d'utiliser une classe générique simulant dynamiquement votre classe. Cet artifice est possible en utilisant l'interface ICustomTypeDescriptor.

Un petit schéma valant mieux qu'un grand discours, voici un petit exemple d'utilisation

NB : le source est disponible ici.

Aprés avoir compilé le projet, copiez l'assembly AM.EnterpriseLibrary.Configuration.Extensions. ApplicationSettings.Design.dll dans le répertoire contenant EntlibConfig.exe. Puis executez celui-ci.

Pour l'exemple, j'ai intégré une classe appelée MyApplication.MySettings dans l'assembly:

Comme on peut le voir, il est possible d'insérer directement des attributs pour controler l'affichage des propriétés.

A l'ouverture du designer, une nouvelle option est disponible "Application Settings" qui va vous permettre d'intégrer votre classe.

Un nouveau noeud est créé contenant une propriété permettant d'indiquer le type de votre classe. L'image suivante montre le sélecteur de type du designer. Pour l'exemple, sélectionnez la classe décrite ci-dessus.

Une fois le type sélectionné, une nouvelle option apparait dans le menu contextuel du noeud Application Settings qui va vous permettre d'instancier votre classe (C'est à ce moment qu'intervient le ICustomTypeDescriptor).

Une fois le noeud créé, vous avez accés aux propriétés de votre classe (Ici un exemple avec un enum)

N'hésitez pas à me faire part de vos remarques ou suggestion.