Code - Financial Independence

Design d’applications – Applications multisolutions

Note: ce sujet est un peu plus complexe en comparaison avec les autres sujets traités durant les tutoriels, si vous ne vous sentez pas assez confortable, vous pouvez procéder avec le prochain tutoriel.

Je dois dire en premier lieu que j’ai été grandement en contact avec ce genre de design durant les derniers mois et je me demande encore pourquoi on s’entête à créer des applications multisolutions.

Qu’est-ce qu’une application multisolutions?

Une telle application contiendra plusieurs solutions et diverses interactions entre elles. Chaque solution contient un ou plusieurs projets et elles peuvent être utilisées autant en Web que du côté Windows. Voici un article interessant discutant du sujet si vous désirez plus d’informations et surtout le pourquoi il n’est pas recommandable d’utiliser ce genre de design dans la majorité des applications.

Quelques exemples?

Voici trois différentes idées de design possibles pour un projet fictif. Le but est de charger de l’information d’un fichier texte et de le transférer dans une base de données. Gardez en tête que le design est la représentation de votre pensée, il est possible que vous ayez un différent point de vue ou encore que ce même design change selon les considérations et la situation du projet. Pour l’instant, gardons le problème simple car c’est seulement pour donner une idée de la structure.

Projet unique

Single Project

Multi-Projet

Multi-Projects

Multisolutions

Multi-Solutions

Les problèmes suivants sont basés sur mon expérience de travail avec des applications créées en multisolutions.

Les choses se corsent!

Se familiariser avec une application multisolution

Les choses peuvent rapidement se compliquer lors de l’apprentissage du fonctionnement de l’application. Dépendamment de sa conception à l’origine, mais dans la plupart des cas, l’application peut référencer différentes parties aussi en construction lançant des erreurs au point qu’il deviendra difficile de trouver d’où elles proviennent.

De plus, dans un environnement Web, dans laquelle chaque solution a son propre site Web, il est possible que l’une ou l’autre des références pose problème, mais que l’on soit mal guidé de penser que le site courant est en erreur alors que cette dernière peut provenir d’ailleurs (une autre solution sur un autre site Web contenant une partie du site courant). En bref, le maintiens et la mise-à-jour de ces sites peuvent devenir très complexes, très rapidement. Ceci au point de perdre le contrôle de l’application et de se retrouver dans un enfer de dépendances et de build configuration qui causes des erreurs dans une ou une autre partie de l’application.

D’après mon expérience, les solutions séparées de notre solution principale devraient avoir des rôles complètement distincts de cette dernière. Il est possible de séparer son application autrement qu’avec plusieurs solutions.

Dépendances, plus de dépendances

Si vous pouvez identifier une solution jouant un peu le rôle de mère de toutes les autres, celle-ci devient une excellente candidate pour la séparation en multiples projets. Une seule solution avec plusieurs projets peut déjà réduire la complexité d’une application Web. Une seule application, un seul push vers le serveur et une seule partie à comparer avec le source control (Team Foundation Server/Git/Subversion). Simplement le fait de devoir contrôler la publication de deux solutions plutôt qu’une constitue une perte de temps et une augmentation de la complexité qui est, dans la majorité des cas, sans fondement. Les dépendances engendrées deviendront rapidement un enfer à gérer.

Relation un pour un entre les projets et solutions

Une relation un pour un entre deux projets/solutions est un excellent indicateur d’un couplage trop fort ou de trop haut niveau et devrait être révisé. Une solution devrait comprendre toutes les dépendances et tous les fichiers requis pour fonctionner en elle même.

Jamais assez imposant

À mon avis, aucun projet n’est assez imposant pour justifier l’utilisation de multiples solutions ou même de plus de 5-10 projets. Dans la plupart des cas, il n’est pas utile de designer pour demain si l’on n’est pas certain de ce qui arrivera vraiment. Le but consiste à garder le projet le plus simple possible et répondant aux besoins du client et l’ajout de fonctionnalités, si plus tard devient le cas, devrait se faire sans problème. Un gros projet, mais simplement pensé (et consistant sur les standards et la forme) reste simple malgré sa taille. Tentez d’épargner de l’ouvrage aux programmeurs qui devront tenter de régler des bogues causés par des fonctionnalités qui ne sont même pas implantées encore.

Pourquoi ne pas plutôt créer plusieurs projets?

Si vous voulez absolument séparer votre application en plusieurs solutions distinctes, pourquoi ne pas le faire au niveau des projets directement. Les projets seront plus faciles à gérer et vous sauveront aussi du temps de compilation et bien des maux de tête. Mais attention à faire la bonne distinction entre les projets car il est possible de trop diviser aussi.

La solution : utilisez des répertoires/namespaces

Visual Studio créera automatiquement un nouveau namespace lors de l’ajout d’un fichier dans votre projet (C#). Vous pouvez utiliser les namespaces (et plus visuellement vos fichiers) pour créer des distinctions entre les différentes parties de votre application sans avoir à créer des référencements et autres. Les namespaces sont simples et, tant que vous respecterez les standards de .NET (ou les vôtres), vous devriez sauver beaucoup de temps aussi à la modification de votre code et même à la compilation!

Voici l’exemple de l’application présentée ci-dessus, divisée en trois projets dans une seule solution : interface utilisateur, Report Processor et Data Access (accès aux données). Un projet par division de l’application me semble vraiment insensé, trois projets pour une application de 1000 lignes et il serait beaucoup plus intuitif de regrouper le tout sous un même projet étant donnée la relation un pour un entre les projets. Simplement le fait que les projets partagent le même but commun de l’application indique, à mon avis, que le regroupement serait un gain en matière de réduction de la complexité et des dépendances inutiles de cette application.

Conclusion

Pourquoi créer plusieurs solutions pour une même application? À mon avis cela dépend de la situation, mais je n’ai encore jamais vu une situation dans laquelle une application à plusieurs solutions s’applique. Gardez le projet et le code le plus simple possible en divisant uniquement avec des namespaces ou à la limite des projets simplifiera grandement la tâche de modification et d’amélioration de votre application. Ceci reste quand même mon opinion et il est possible que vous ayez un autre point de vue, sentez-vous donc à l’aise de commenter sur le sujet!

Next article Standards de Code - Mot-clé Var en C#
Previous article Visual Basic/C# - Les Windows Forms plus en détails (Partie 2)

Related posts