Dossiers ou projets dans une solution Visual Studio?

Lorsque vous répartissez une solution dans des couches logiques, à quel moment est-il préférable d'utiliser un projet distinct plutôt qu'un regroupement par dossier?

0

7 Réponses

Je fais habituellement un projet pour l'interface utilisateur graphique un projet pour la logique métier un projet pour l'accès aux données et un projet pour les tests unitaires.

Mais parfois, il est prudent d'avoir une séparation basée sur les services (si vous utilisez une architecture orientée service) comme l'authentification, les ventes, etc.

Je suppose que la règle empirique à laquelle je travaille est la suivante: si vous pouvez voir cela comme un élément qui présente une séparation claire des préoccupations, alors un projet différent pourrait être prudent. Mais je pense que les dossiers par rapport aux projets pourraient être juste une préférence ou une philosophie.

Personnellement, je pense que si le code réutilisable est divisé en projets, il est plus simple d'utiliser d'autres endroits que s'il s'agit uniquement de dossiers.

0
ajouté

La séparation des entités en projets est souvent une optimisation de l'architecture YAGNI. Combien de fois avez-vous réutilisé ces projets séparés, vraiment? Si ce n'est pas fréquent, vous compliquez votre développement, votre build, votre déploiement et votre maintenance pour une réutilisation théorique.

Je préfère de loin séparer en dossiers (en utilisant les espaces de noms appropriés) et refactoring pour séparer les projets lorsque vous avez un cas d'utilisation de réutilisation de la vie réelle.

0
ajouté
Quand je remplace «réutilisation théorique» par «test», votre conclusion est-elle toujours valable?
ajouté l'auteur reinierpost, source

Séparer votre code source en   plusieurs projets ne fait que sens si   toi...   ... Plus de développeurs impliqués   et vous voulez traiter leur travail comme   boîte noire consommable. (pas très   recommandé) ...

Pourquoi n'est-ce pas recommandé? J'ai trouvé cela très utile pour gérer une application avec plusieurs devs travaillant sur différentes parties. Rend les checkins beaucoup plus faciles, principalement en éliminant pratiquement les fusions. Très rarement, deux développeurs doivent travailler sur le même projet en même temps.

0
ajouté
Il est seulement recommandé pour le code qui est suffisamment stable pour permettre des responsabilités claires et des interfaces pour les projets à déterminer.
ajouté l'auteur reinierpost, source

Si vous décidez de créer plusieurs projets, assurez-vous que tous ceux qui ajoutent du code à la solution sont pleinement conscients de leur intention et font tout leur possible pour les amener à comprendre les dépendances entre les projets. Si vous avez déjà essayé de régler le problème quand quelqu'un est parti et ajouté des références qui n'auraient pas dû être là et qui vous ont échappé pendant des semaines, vous comprendrez ce point

0
ajouté

Par défaut, créez toujours un nouveau dossier dans le même projet

  • Vous obtiendrez un assemblage unique (sans gymnastique ILMerge supplémentaire)
  • Plus facile à obscurcir (parce que vous aurez moins de types et de méthodes publics, idéalement pas du tout)

Séparer votre code source en plusieurs projets n'a de sens que si vous ...

  • Certaines parties du code source font partie du projet mais ne peuvent pas être déployées par défaut ou du tout (tests unitaires, plugins supplémentaires, etc.)
  • Plus de développeurs impliqués et vous voulez traiter leur travail comme une boîte noire consommable. (pas très recommandé)
  • Si vous pouvez séparer clairement votre projet en couches / modules isolés et que vous voulez vous assurer qu'ils ne peuvent pas consommer de manière croisée des membres internes . (également déconseillé car vous devrez décider quel aspect est le plus important)

Si vous pensez que certaines parties de votre code source pourraient être réutilisables, ne le créez pas en tant que nouveau projet. Attendez juste que vous vouliez vraiment le réutiliser dans une autre solution et l'isoler du projet original au besoin. La programmation n'est pas un lego, la réutilisation est généralement très difficile et souvent ne se fera pas comme prévu.

0
ajouté
J'aime le sens de la réalité de lubos.
ajouté l'auteur ybakos, source

denny a écrit:

Personnellement, je pense que si le code réutilisable est divisé en projets, il est plus simple d'utiliser d'autres emplacements que s'il s'agit de dossiers.

Je suis vraiment d'accord avec cela - si vous pouvez le réutiliser, il devrait être dans un projet distinct. Cela dit, il est également très difficile de réutiliser efficacement :)

Ici, à SO, nous avons essayé d'être très simple avec trois projets:

  • Projet Web MVC (qui permet de séparer vos calques en dossiers par défaut)
  • Projet de base de données pour le contrôle de la source de notre DB
  • Tests unitaires sur des modèles / contrôleurs MVC

Je ne peux pas parler pour tout le monde, mais je suis content de la simplicité avec laquelle nous l'avons gardé - accélère vraiment les constructions!

0
ajouté

Je pense vraiment qu'il vaut mieux partager le projet, mais tout dépend de la taille du projet et du nombre de personnes qui y travaillent.

Pour les grands projets, j'ai un projet pour

  • accès aux données (modèles)
  • services
  • frontal
  • tests

J'ai eu le modèle de Rob Connery et son application de vitrine ... semble fonctionner très bien.

mvc-vitrine

0
ajouté