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 ?
Bonjour et merci pour cet article. Je développe (seul) depuis pas mal de temps sous VS en C# Winforms et je n’avais jamais fait attention à ces “dossiers solution” !
J’ai trouvé votre article car je suis à la recherche d’une nouvelle organisation de mes codes sources. J’ai mis en place une organisation il y a plusieurs années et j’en suis satisfait mais aujourd’hui je la remet en cause car je pense utiliser GIT.
Je suis conscient que GIT n’est pas le sujet de votre post, que comme vous le précisez il existe plusieurs organisations de code source mais comme vous semblez avoir une bonne expérience avec plusieurs clients vous pouvez peut être m’aider à y voir plus clair. De plus je vois une arbo Git dans vos copie d’écran.
Voici mon orgnisation : j’ai développé plus d’une trentaine de DLL (utilitaire, métier, données…). Chacune de mes DLL correspond à un projet et à une solution (1 dll => 1 projet => 1 solution). Pour la compile je me suis fait un petit programme de build pour générer mon framework et copier mes fichier *.DLL dans un répertoire unique (ce qui facilite l’ajout de référence dans mes appli et le passage DEBUG/RELEASE) . Donc dés que je dois réaliser une application je puise mes références dans ce dossier unique.
Avec GIT je me demande si je ne devrais pas regrouper tous mes projets “DLL” dans une même solution afin de faciliter la gestion de différentes versions de mon framework (cas de maintenance). Ma crainte est justement (on en revient à votre article) que plus de 30 projets (augmentation constante) à gérer dans VS sera un peu galère…. Avez vous un conseil à me donner ? Merci
Bonjour et merci pour ce commentaire ! Voici la réponse de notre expert Rémi Sorlin :
“Déjà il ne faut pas confondre Solution VS et repo Git. Il peut y avoir plusieurs solutions dans un seul et même repo Git. Pour la gestion des versions, c’est plutôt un seul repo Git mais il est aussi possible de continuer à avoir un projet par solution.
Si la gestion multi solutions convient, il vaut mieux ne pas changer de méthode. Vous ne devez pas avoir besoin d’ouvrir plusieurs projets à chaque modification sinon vous aurez déjà tout rassemblé.
Si vous voulez pouvoir gérer des branches Git par version (git flow classique avec release branch) il vous faut un seul repo Git. Une seule solution ou plusieurs, c’est vraiment à votre convenance : si vous pouvez travailler sur un seul projet à la fois, une solution par projet c’est bien. Si au contraire chaque modification implique d’ouvrir et de travailler dans plusieurs projets, c’est peut être mieux de rassembler dans une solution et organiser en dossiers. Mais ce choix n’est pas guidé par le passage sous Git.”
Merci j’en avais vraiment besoin..
Merci pour cet article,
Je viens de découvrir une fonctionnalité intéressante de Visual.
Je bookmark le blog.
Merci pour votre retour.