Organiser son code dans sa solution Visual Studio

En tant que consultant .NET, on est amené à créer de nouveaux projets et à travailler sur des solutions Visual Studio existantes chez nos clients. Même si l’on retrouve communément certaines briques dans les différents projets que l’on rencontre, on tombe plus rarement sur des projets organisés de la même manière. Cela s’explique par le fait qu’aucun projet n’est bâti de la même façon au cours des années, mais surtout que tous les projets sont différents les uns des autres. Pourtant, quand on y regarde de plus près, on retrouve toujours des couches communes : je pense notamment à la couche métier (BL), la couche d’accès au données (DAL), le(s) site(s) web (UI), les traitements (CMD, Services Windows, etc), les Helpers communs (couches transverses, framework maison, etc). Voyons donc dans quelle mesure on peut organiser tout son code dans sa solution Visual Studio.

Les projets grossissent au fil du temps

Force est de constater que les projets s’empilent, au fil du temps, au sein d’une solution Visual Studio. Malheureusement, le code qui se rajoute ne respecte pas forcément une organisation logique : on a tous connu les appels directs à la DAL depuis nos projets WebForms (voire même les requêtes SQL en dur dans les pages Web pour le chargement des GridViews). Par ailleurs, lorsque notre solution commence à atteindre un nombre élevé de projets (on a parfois du mal à ouvrir toute notre solution et on pleure quand on fait ctrl + shift + B), on s’y perd assez vite et du coup on est moins efficace en travaillant sur le projet et on tombe dans la facilité :  le mode patch, réécriture de fonctions déjà existantes. S’en suivent exaspération, bugs qui n’arrêtent pas, et surtout régressions… Bon j’avoue, ce n’est pas tout le temps comme ça mais ça arrive plus souvent qu’on ne le croit.

Comment organiser alors sa solution Visual Studio ?

La principale solution est simple et pourtant, dans la majorité des cas, on n’y pense pas : il suffit de regrouper ses projets de même catégorie notamment en les rangeant dans des dossiers de solutions. Dans la majorité des cas, cette solution est la meilleure mais certaines architectures (type hexagonales par exemple) vont engendrer une approche un peu différente en termes d’organisation logique.

Utiliser les dossiers de solutions

Un dossier de solution est simplement un dossier “virtuel” que l’on peut créer dans la solution Visual Studio afin d’organiser son code. Il n’impacte pas vos dossiers physiques de projet. Par défaut, Visual Studio ajoutera à la racine les projets que vous rajouterez à votre solution :

En faisant un clique-droit sur notre solution (ici : SuperProject),puis ‘Add’, puis ‘New Solution Folder’, nous rajoutons donc un dossier de solution.

Plus tôt vos dossiers de solutions seront rajoutés, plus simple sera l’ajout de nouveaux projets de façon organisée dans votre solution. Mais, bien entendu, on ne peut pas tout prévoir à l’avance :). On peut donc imaginer un projet exemple ressemblant à ceci :

Ordonner logiquement les dossiers de solutions

Une fois l’utilisation des dossiers de solution maîtrisée, on peut rajouter un peu de piment à notre sauce en ordonnant logiquement nos dossiers. En effet, si nous découpons logiquement notre code en modèle en couches linéaires, on va avoir des strates supérieures qui s’appuieront sur des couches plus basses. Un exemple classique est celui du site web qui s’appuie sur une couche de service ou métier, qui s’appuie elle-même sur une couche d’accès aux données. Pour respecter cet ordre, on va simplement mettre un numéro d’ordre en entête du nom de nos dossiers de solution (qui ne sont visibles que dans notre solution Visual Studio) :

J’ai choisi arbitrairement des nombres à 2 chiffres afin de rajouter facilement des numéros intermédiaires : par exemple, je pourrais rajouter un dossier “WebAPI” entre le dossier “Business” et “Web”,  je le nommerais alors “25-WebApi”.

Garder la cohérence avec les dossiers physiques

En rajoutant depuis la solution des nouveaux projets dans des dossiers de solution, ceux-ci sont créés dans le répertoire racine de la solution par défaut. Afin de garder une certaine cohérence avec notre hiérarchie logique de notre solution Visual Studio et de rendre plus fluide la consultations des projets, on peut, au moment de rajouter un nouveau projet spécifié, créer un dossier du même nom que notre dossier de solution. Cela évite au passage de se retrouver avec plusieurs dizaines de projets plus ou moins différents fonctionnellement parlant au même niveau dans l’arborescence physique.

Respecter le nommage des projets

Les conventions de nommage sont à respecter afin de faciliter la lisibilité et donc la compréhension du code dans une solution. Concernant les projets de la solution, cela n’est pas une obligation mais il est préférable de respecter un certain standard décidé par notre équipe, ou imposé par votre organisation. Cela permettra également de manipuler plus aisément vos espaces de noms (namespaces). Un exemple de nommage appliqué dans mes exemples ci-dessus :
NomDeMontreprise.NomDeMonServiceOuEtNomDuProjet.NomDeMonProjectVs. Ce qui pourrait donner par exemple : Cellenza.Marketing.WebSite.
A chaque équipe de trouver le namaspace qui lui correspond le mieux.

Nommage par intention

En continuant sur notre idée de départ, on peut étendre cette logique d’organisation des projets de notre solution Visual Studio au niveau des projets eux-mêmes :

Ceci est un exemple illustratif pour rappeler encore une fois l’importance de l’intention dans le code de façon générale, comme je l’ai expliqué lors de mon article précédent.

Attention à l’over-design

Bien qu’il s’agisse ici d’un découpage et d’une organisation logique de nos projets et code, on est toujours tenté de “designer” toute notre solution en prévoyant un maximum de cas : le risque est de se retrouver dans la même solution Visual Studio avec un découpage logique trop fin et une longue liste de projets, ce qui au final pourrait entraîner l’effet contraire, c’est à dire la non- lisibilité de notre code, avec la sensation de surcharge. En outre, et surtout, le risque est de se retrouver avec des projets/couches qui ne sont pas nécessaires à l’instant T, et potentiellement pas utiles par la suite (YAGNI !). Ces projets/couches pourraient ainsi générer du bruit dans notre solution, la surcharger et appauvrir notre lisibilité du code. Si on a besoin que d’un site internet avec aucune interaction avec d’autres systèmes techniques environnants, nul besoin de faire des dossiers de solution.

Conclusion

Cet article pour rappeler qu’il n’y a pas que le fond qui compte, mais aussi la forme : tout comme on oublie généralement d’intégrer en début de projet la gestion de langue (internationalisation/globalisation) en pensant qu’on aura le temps de le faire après sans difficulté, il en est de même pour l’organisation des projets de notre solution Visual Studio. En empilant les projets dans notre solution sans les organiser au départ, on prend le risque de perdre du temps à la faire par la suite (modification des fichiers .csproj et .sln à la main) et d’alourdir notre solution. La présentation et l’organisation de vos projets Visual Studio, à l’image de votre armoire bien rangée, facilitera la prise en main par tout nouveau arrivant sur un projet .NET. Mieux, il facilitera pour vous même la lisibilité de votre code, notamment en vous simplifiant la recherche de certains modules si ces derniers sont bien rangés selon votre logique.

Je tiens cependant à préciser qu’il n’y a pas d’organisation parfaite (sinon ça se saurait), mais qu’il existe une organisation de code adapté à chaque équipe et projet. L’essentiel est que toute l’équipe partage et adhère à un choix d’organisation de code qui a été fait.

Un autre point qui me semble important à relever est que l’on ne peut pas tout prévoir à l’avance : nous devons donc éviter de tomber dans le piège de l’over-design, et d’implémenter en priorité ce dont on a besoin à court terme et organiser son code en conséquence avec des anticipation plutôt fines et légères. En tant voulu, des refactoring s’imposeront et cela est tout à fait normal.

Amis lecteurs, qu’en pensez-vous ? Comment organisez-vous votre code ?