[.Net] Gestion d’un framework
Cet article est valable pour tous les types de Framework mais l’exemple que m’occupe concerne plus particulièrement Silverlight.
Mise en place du décor:
Dans mon projet actuel, je suis impliqué dans un Framework ayant pour but de fournir des contrôles Silverlight aux autres projets en cours dans la boite.
La semaine dernière avec mon responsable, nous avons ouvert un débat: “Quelle est la meilleure manière de gérer les namespaces ?”
La première approche que nous avons suivie consistait en ces 2 principes :
- Chaque contrôle ou groupe de contrôles liés (par exemple TabControl et TabItem) ont un répertoire dédié.
- Les namespaces collent à la hiérarchie physique interne du projet
Nous avions donc des namespaces qui ressemblent à “CompanyName.ProjectName.AssemblyName.FolderName”
Ce qui a pour résultat dans le cas des TabControl et TabItem custom de donner les noms complets suivants:
- CompanyName.ProjectName.AssemblyName.TabControl.CustomTabControl
- CompanyName.ProjectName.AssemblyName.TabControl.CustomTabItem
Description du problème :
Le Framework a pas mal évolué depuis ses débuts et nous avons maintenant plusieurs dizaines de contrôles. Cela implique que nous avons également plusieurs dizaines de namespaces.
Pour certains contrôles nous avons également créé des librairies dédiées. Ainsi nous avons 2 type de DataGrid différentes et chacune a son assembly.
Solution possible :
En regardant comment d’autres gèrent cela, nous nous sommes attardé sur la solution type Microsoft.
En effet, l’exemple de Microsoft nous montre qu’il n’est pas du tout nécessaire de créer une collection de namespace. Leur approche tout à fait différente. Par exemple, l’assembly System.Windows.Controls (http://msdn.microsoft.com/en-us/library/system.windows.controls.aspx) contient tous les contrôles de la librairie sans “sous-namespace”.
Plus interpellant, d’autres librairies rajoutent parfois du contenu directement dans System.Windows.Controls…
Il y a également certains contrôles tels que la DataGrid qui arrive dans System.Windows.Controls.Data.
Le choix effectué :
L’approche Microsoft est plutôt tentante car elle nous permettrait de limiter les namespace devenant très encombrants. Elle a toutefois un désavantage conséquent : un seul folder pour contenir des dizaines de classes ça fait rapidement désordre.
Nous avons donc décidé de casser la règle prise au début qui disait que “Les namespaces collent à la hiérarchie physique interne du projet”.
Nous avons donc réussi à éliminer nos namespaces inutiles mais également à garder un certain ordre permettant une gestion et une maintenance facile.
Et vous ?
Pour être tout à fait honnête, le but de ce post était double.
Il me permet de partager avec vous le process qui nous suivons mais également de vous demander de quelle manière vous feriez.
Qui sait, nous n’avons pas encore commencé le refactoring, nous trouverons peut-être de très bonnes idées dans vos approches personnelles.
Au plaisir de vous lire…
A bientôt,
DjoDjo
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
