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 il est parfois 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 d'or sur laquelle je travaille est que si vous pouvez le voir comme un composant qui a 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 n'être qu'une préférence ou une philosophie.

Je pense personnellement que si le code réutilisable est divisé en projets, il est plus simple d'utiliser d'autres endroits que s'il se trouve uniquement dans des dossiers.

denny a écrit :

Je pense personnellement que si le code réutilisable est divisé en projets, il est plus simple d'utiliser d'autres endroits 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 calques dans des 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 au nom de tout le monde, mais je suis satisfait de la simplicité avec laquelle nous l'avons gardé : cela accélère vraiment les builds !

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...

• 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 utiliser de manière croisée les 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 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 souvent ne se déroulera pas comme prévu.

Séparer votre code source en plusieurs projets n'ont de sens que 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é 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 pratiquement les fusions. Il est très rare que deux développeurs doivent travailler sur le même projet en même temps.

La séparation des fonctionnalité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 création, 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 de réutilisation réel.

Si vous optez pour la création de plusieurs projets, assurez-vous que tous ceux qui ajoutent du code à la solution sont pleinement conscients de leur intention et faites tout ce que vous pouvez 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 qui s'en sont tirées pendant des semaines, vous comprendrez ce point