avantages de plusieurs projets et d’une solution

Je travaillais en entreprise, nous utilisons plusieurs projets dans les projets de solution pour l’interface utilisateur, la logique métier, l’access aux données, la firebase database et un autre pour l’impression …. mais maintenant je suis dans une nouvelle entreprise Ne pas avoir à faire tout ce projet, je dois juste les faire dans un répertoire séparé dans un projet de la solution.

Je veux juste savoir si je dois le convaincre d’utiliser plusieurs projets!

Je suis d’accord avec votre manager.

Plusieurs projets signifie plusieurs assemblages, beaucoup de copie autour d’ensembles et des temps de compilation généralement plus lents.

Si votre seule raison d’avoir plusieurs projets est une organisation améliorée, vous le faites mal. Il serait tout aussi efficace d’utiliser des dossiers.

Voici quelques raisons valables d’avoir différents assemblages:

  • Vous avez une architecture de plugin
  • Vous devez déployer des assemblages séparément
  • Vous devez travailler dans plusieurs langues
  • Vous créez des bibliothèques à utiliser dans différents endroits

Je suis très surpris par la réponse acceptée. J’ai travaillé dans les deux environnements et j’ai constaté que plusieurs projets étaient globalement bénéfiques. La décision réelle incombe toujours à votre équipe (si un seul projet ne vous empêche pas d’atteindre vos objectives, il est alors suffisant).

Je m’appuie sur les principes OOD d’ oncle Bob concernant la gestion des paquets. Celles-ci ne sont pas très connues (surtout comparées à ses principes SOLID pour la conception de classe) mais elles sont raisonnables.

Tiré des Principes d’OOD de l’Oncle Bob

Les trois premiers principes de paquet concernent la cohésion de paquet, ils nous disent quoi mettre dans les paquets:

  • REP Principe d’équivalence de réutilisation des versions Le granule de réutilisation est le granule de libération.
  • CCP Le principe de fermeture commun Les classes qui changent ensemble sont emballées ensemble.
  • CRP Principe de réutilisation courante Les classes utilisées ensemble sont empaquetées ensemble.

Les trois derniers principes concernent les couplages entre les packages et parlent de mésortingques qui évaluent la structure de packages d’un système.

  • ADP Principe des dépendances acycliques Le graphe de dépendance des packages ne doit comporter aucun cycle.
  • SDP Principe des dépendances stables Dépend de la stabilité.
  • SAP Le principe des abstractions stables L’abstraction augmente avec la stabilité.

Celles-ci correspondent à mon expérience personnelle dans laquelle le fait de pencher vers moins de projets a souvent entraîné des problèmes dans mon expérience:

  • Moins de paquets peut entraîner une mauvaise gestion de la dépendance. Des projets / assemblages séparés peuvent aider à empêcher les classes et membres internes / privés d’être utilisés là où ils ne devraient pas être.

  • Généralement, avec de nombreux projets, vous développez un ensemble de bibliothèques “essentielles” très stable et testé, qui changent très rarement. Conserver ces composants dans leur propre projet (ou même leur solution) peut les protéger des modifications en cours dans les couches supérieures.

  • Les grands projets résultant de l’utilisation de moins (ou d’un seul) projet peuvent être très indisciplinés. Visual Studio ne définit pas l’attente que votre projet / solution reflète votre structure de fichier, de sorte qu’un grand projet organisé peut toujours exister de manière chaotique sur votre lecteur.

  • Visual Studio est suffisamment intelligent pour éviter de recomstackr des assemblys sans modification. Au fur et à mesure que vos projets “de base” se stabilisent, ils verront moins de compilations, ce qui leur fera gagner du temps.

  • De même qu’avec ce qui précède, utiliser moins de projets conduit à toujours recomstackr le code, qu’il comporte ou non des modifications pertinentes. Un changement d’une ligne dans un très grand projet entraînera une recompilation complète.

Bien entendu, plusieurs projets peuvent avoir leurs problèmes:

  • Vous devez être conscient de vos dépendances afin d’éviter les références cycliques (que .NET gère assez bien, mais Visual Studio fonctionne pour empêcher)

  • Vos solutions peuvent devenir suffisamment grandes pour justifier des sous-solutions, ce qui peut être délicat à gérer

  • Les temps de compilation initiaux d’une solution peuvent être plus lents

Enfin, une caractéristique rarement utilisée dans .NET est qu’un seul fichier .DLL peut contenir plusieurs modules (en réalité, il s’agit de plusieurs assemblys partageant un seul ensemble de métadonnées). Je ne suggérerais pas d’utiliser ceci, mais il est intéressant de savoir que c’est comme ça que ça marche: http://www.codeproject.com/Articles/9364/Merging-NET-assemblies-using-ILMerge

J’ai trouvé un article intéressant sur l’importance de la structure (qu’il s’agisse d’un projet ou d’un dossier) au sein d’applications. Je dirai que lorsque vous ouvrez une solution et que vous voyez une liste de noms de projets, ils me donnent une indication de la manière dont l’application a été créée. Etc

(Exemple de modèle de conception MVP)

  1. BLL (Affaires)
  2. DAL (persistance (mappages, conventions, etc.))
  3. Web
  4. PL (couche de présentation)
  5. Test (il est certain que des tests doivent être effectués dans un projet séparé)

La structure du répertoire est fondamentale pour votre code

“Comme tout concepteur vous le dira, ce sont les premières étapes d’un processus de conception qui comptent pour la plupart. Les premiers traits, qui créent la forme, portent en eux le destin du rest.” – Christopher Alexander

(Christopher Alexander est un architecte. Sans avoir travaillé comme programmeur, il a beaucoup influencé la programmation. Son premier livre, A Pattern Language, était l’inspiration originale du mouvement Design Patterns. Il a longuement réfléchi à la manière de construire de belles choses, et ces reflections semblent s’appliquer aussi largement à la construction de logiciels).

Dans une interview à la radio de CBC, Alexander a raconté l’histoire suivante (paraphrasée ici): “Je travaillais avec un de mes étudiants. Il avait beaucoup de difficulté à construire quelque chose. Il ne savait tout simplement pas comment procéder. Je me suis assis avec lui et j’ai dit ceci: Écoutez, commencez par déterminer ce qui est le plus important. Commencez par comprendre ça directement. Considérez cela directement dans votre esprit. Prenez votre temps. Ne soyez pas trop pressé. Réfléchissez-y. Lorsque vous avez l’impression de l’avoir trouvée, et qu’il ne fait aucun doute dans votre esprit que c’est effectivement la chose la plus importante, allez-y et faites-la plus importante. Quand vous avez créé cette chose la plus importante, posez-vous la question suivante: Si vous pouvez le rendre plus beau. Coupez les conneries, juste l’obtenir dans votre tête, si vous pouvez l’améliorer ou pas. Quand c’est fait, et vous sentez que vous ne pouvez pas l’améliorer, alors trouvez la prochaine chose la plus importante . ”

Quels sont les premiers traits d’une application, qui créent sa forme globale? C’est la structure du répertoire. La structure de répertoires est la toute première chose rencontrée par un programmeur lorsqu’il navigue dans le code source. Tout en découle. Tout en dépend. C’est clairement l’un des aspects les plus importants de votre code source.

Prenez en compte les différentes réactions d’un programmeur lorsqu’il rencontre différentes structures de répertoires. Pour le style package-by-feature, la pensée du programmeur d’application pourrait être la suivante:

“Je vois. Cela répertorie toutes les fonctionnalités de haut niveau de l’application en une seule fois. Nice.” “Voyons voir. Je me demande où se trouve cet object … Oh, le voici. Et tout le rest dont j’ai besoin est ici aussi, tous au même endroit. Excellent.” Pour le style paquet par couche, cependant, les pensées du programmeur d’application pourraient ressembler davantage à ceci: “Ces répertoires ne me disent rien. Combien de fonctionnalités dans cette application? Cela me dépasse. Cela a exactement la même apparence que tous les autres. Aucune différence du tout. Génial. Nous y revoilà … “” Hmm. Je me demande où se trouve cet élément … Je suppose que ses pièces sont réparties dans l’application, réparties dans tous ces répertoires. Ai-je vraiment tous les articles dont j’ai besoin? Je suppose que nous le saurons plus tard. ” “Je me demande si cette convention de dénomination est toujours respectée. Sinon, je devrai la rechercher dans cet autre répertoire.” “Wow, regardez-vous la taille de ce seul répertoire… sheesh.” L’empaquetage par couche dans d’autres domaines est inefficace

La source

En raison de la séparation des préoccupations. Cela aidera grandement les références inattendues entre classes / objects.

Pour les programmeurs WPF / Silverlight, réfléchissez au modèle de conception de MVVM: séparer ViewModels et Views en deux projets distincts garantira l’absence de référence d’un object View dans un ViewModel.

Un autre point est le temps de construction qui pourrait être plus court car la solution entière ne sera pas recompilée à chaque fois. Cela pourrait être un bon argument pour votre responsable (mais cette hypothèse peut être fausse en fonction de la taille de votre solution).

Si vous n’avez qu’une seule application, alors un seul projet convient. Mais je pense que c’est très rare. La plupart du temps, vous aurez plusieurs applications. Ainsi, si vous avez plusieurs projets, vous pouvez réutiliser des composants entre les applications sans avoir à faire des choses difficiles comme le partage de fichiers source.

Utilisez différents projets, si vous avez besoin

  • Fichiers binarys séparés pour votre solution, vous êtes ainsi flexible dans la préparation et le déploiement de correctifs / mises à jour

  • Possibilité de gérer des plugins

  • Utilisation, par exemple, de codes C ++ dans votre C #.

  • Utilisation de composants réutilisables. Les types déclarés dans les assemblys peuvent être réutilisés dans différentes applications de votre entreprise pour fournir des API uniformes.