Dossiers ou projets dans une solution Visual Studio ?[fermé]

Question

Lors de la division d'une solution en couches logiques, quand est-il préférable d'utiliser un projet distinct plutôt qu'un simple regroupement par dossier ?

Answer 1

Par défaut, créez toujours simplement un nouveau dossier au sein d'un même projet

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

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

• Avoir certaines parties du code source qui font partie du projet mais qui ne sont pas déployables par défaut ou pas du tout (tests unitaires, plugins supplémentaires, etc.)
• Plus de développeurs sont impliqués et vous souhaitez traiter leur travail comme une boîte noire consommable.(pas très recommandé)
• Si vous pouvez clairement séparer votre projet en couches/modules isolés et que vous voulez vous assurer qu'ils ne peuvent pas être consommés de manière croisée interne membres.(non recommandé non plus 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 simplement de vouloir vraiment le réutiliser dans une autre solution et isolez-le du projet d'origine si nécessaire.La programmation n'est pas un lego, la réutilisation est généralement très difficile et ne se déroule souvent pas comme prévu.

Answer 2

Séparer les fonctionnalités en projets est souvent une optimisation de l'architecture YAGNI.À quelle fréquence avez-vous vraiment réutilisé ces projets séparés ?Si ce n'est pas fréquent, vous compliquez votre développement, votre construction, votre déploiement et votre maintenance pour une réutilisation théorique.

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

Answer 3

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 se trouve uniquement dans des dossiers.

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

Chez SO, nous avons essayé d'être très simples avec trois projets :

• Projet Web MVC (qui fait un bon travail en séparant vos couches en dossiers par défaut)
• Projet de base de données pour le contrôle des sources de notre base de données
• Tests unitaires par rapport aux modèles/contrôleurs MVC

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

Answer 4

Je fais habituellement un projet pour l'interface 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 services) tels que l'authentification, les ventes, etc.

Je suppose que la règle empirique sur laquelle je travaille est que si vous pouvez le voir comme un composant dont les préoccupations sont clairement séparées, alors un projet différent pourrait être prudent.Mais je pense que les dossiers par rapport aux projets pourraient simplement être 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 emplacements que s'il se trouve uniquement dans des dossiers.

Answer 5

La séparation de votre code source en plusieurs projets n'a de sens que si vous ......Plus de développeurs impliqués et vous souhaitez traiter leur travail comme une boîte noire consommable.(Pas très recommandé) ...

Pourquoi n’est-ce pas recommandé ?J'ai trouvé que c'était un moyen très utile de gérer une application avec plusieurs développeurs travaillant sur différentes parties.Rend les enregistrements beaucoup plus faciles, principalement en éliminant virtuellement les fusions.Il est très rare que deux développeurs doivent travailler sur le même projet en même temps.

Answer 6

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 faites tout ce qui est en leur pouvoir pour leur faire comprendre les dépendances entre les projets.Si vous avez déjà essayé de régler le problème lorsque quelqu'un est parti et a ajouté des références qui n'auraient pas dû être là et s'en est sorti pendant des semaines, vous comprendrez ce point.

Answer 7

Je pense vraiment qu'il est préférable de diviser le projet également, mais tout dépend de la taille du projet et du nombre de personnes qui y travaillent.

Pour les projets plus importants, j'ai un projet pour

• accès aux données (modèles)
• prestations de service
• l'extrémité avant
• essais

J'ai reçu le modèle de Rob Connery et de son application de vitrine...ça a l'air de très bien fonctionner.

vitrine mvc