Question

Combien de projets dans une solution unique est acceptable? Et pour les applications qui ont un grand nombre de projets, placez-vous les autres DLL compilées dans un dossier commun pour pouvoir exécuter l'application?

Était-ce utile?

La solution

Etant donné qu'un projet est compilé dans un assemblage dans Visual Studio, la question que vous devez vous poser est la suivante: "Combien d'assemblages dois-je avoir?"

S'il n'y a aucune raison d'utiliser les assemblages séparément, il ne devrait y avoir aucune raison de les séparer dans plusieurs projets. Si vous avez plusieurs assemblages pour appliquer la superposition, c’est à cela que servent les espaces de noms.

Dans une configuration idéale, vous devez avoir un projet (= un assemblage) pour chaque hôte différent de votre application et un pour votre logique non spécifique à l'hôte.

YMMV cependant, vous pouvez diviser les projets en fonction de ceux qui travaillent sur les différentes parties, mais essayez en fait de limiter le nombre de projets dans votre solution (au moment où j'écris ceci, j'ai du mal à + solution de projets, alors je parle des gouffres de mon expérience personnelle).

Vous trouverez une discussion intéressante sur les couches logiques / physiques d'applications sur le blog de Patrick Smacchia (par exemple, http://codebetter.com/blogs/patricksmacchia/archive/2008/02/10/layering-the-level- métrique-et-le-discours-de-méthode.aspx )

Autres conseils

Eh bien, 42 ans bien sûr!

Il n’ya pas de bonne ou de mauvaise réponse à cette question. Certains développeurs aiment créer plusieurs projets dans le projet principal. D'autres aiment compiler un assemblage (la dll) et faire référence à. Cela dépend de votre équipe et de votre lieu de travail.

Je suis d'accord avec les réponses jusqu'à présent. Un critère supplémentaire est la rapidité de reconstruction de la solution ...

Je pense que cela dépend de la taille et du type de vos projets. mais de par ma propre expérience, lorsque le nombre de projets est supérieur à 5, le processus de construction prendra du temps. J'essaie donc de conserver les projets que je n'ai pas besoin de changer fréquemment dans une autre solution afin d'accélérer le processus de construction.

Tant que chaque projet est une fonctionnalité valide distincte, et que tous les projets sont étroitement couplés (dans la mesure du but), alors ce n'est pas un problème.

Ce que je fais, c’est que j’ai un " Bibliothèques " projet où je mets toutes mes DLL externes, puis les référencer directement là.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top