La structure ultime des solutions Visual Studio

Question

Sachant que cela peut être subjectif en fonction du projet en cours, je cherche la méthode de "meilleure pratique" pour structurer une solution VS.

N'hésitez pas à modifier ce document, à commenter ce que vous pensez être incorrect, à suggérer des alternatives, etc. J'aimerais que ce CW devienne une ressource importante pour les personnes qui débutent avec VS Solutions.

Voici ce qui fonctionne pour moi actuellement (sur mon projet actuel), mais je sais pertinemment qu'il y a des choses au mauvais endroit. Dans mon scénario, je construis un Application web en utilisant MVC 2

Veuillez poster votre idée de la structure de la solution finale afin que nous puissions nous faire une idée de la "meilleure façon" / "meilleure pratique" ( quoi que cela veuille dire exactement )

IE :
Comment répartissez-vous vos DAL / BLL ?
Placez-vous votre couche de référentiel et votre couche de service dans votre BLL ?
Si vous utilisez MVC, gardez-vous vos contrôleurs dans l'interface utilisateur plutôt que dans le noyau ?
Est-ce que vous mettez beaucoup de choses dans vos dossiers Utilitaires/Divers, ou est-ce que vous les séparez encore plus ?
etc...

---

• MySolution
  • MySolution.Core
    • Authentification
      • C'est ici que j'ai un POCO et une méthode pour searialize le poco dans la secion userData du cookie d'authentification.
    • Base
      • c'est ici que je garde mon BaseController et par BaseGlobal
    • Contrôleurs
      • toutes mes manettes (évidemment)
    • Domaine
      • Modèles de base de données
        • contient mon fichier L2S .dbml
      • JsonModels
        • modèles utilisés pour passer des objets JSON au veiw
      • Dépôts
      • Services
      • ViewModels
    • Extensions
      • toutes les méthodes d'extension
    • Filtres
      • Filtres d'action
    • Utilitaires
      • Apis
        • tout le code de l'API d'un tiers va ici
      • Badges
        • Le calcul du badge se fait ici
      • MailClient
        • envoyez des e-mails en texte brut ou en html en utilisant les classes présentes ici
      • RoutingHelpers
        • contient une classe pour activer les routes en minuscules
      • contient aussi des choses que je ne sais pas où mettre ailleurs... IE : HTMLSanitizer, HtmlHelpers personnalisé, UserInfo helper (adresse IP, navigateur, etc), DataConverter, etc...
  • MySolution.UI
    • App_Browsers
    • Actifs
      • Css
      • Images
      • Scripts
    • Vues
    • Global.asax - hérite de BaseGlobal
    • Web.config

---

Captures d'écran

N'hésitez pas à commenter en conséquence, ou mieux encore, à poster votre propre version (réponse) ci-dessous. Je sais que ce que j'ai n'est pas la meilleure solution.

Answer 1

Beau Wiki.

Je commence un nouveau projet, et c'est la structure avec laquelle j'ai commencé.

Il suit les meilleures pratiques de Microsoft (Business, Data, Services, Presentation).

Dans ma solution :

• Entreprise : logique spécifique au domaine/projet, et plus particulièrement les POCO.
• Données : référentiels. Auto-explicatif.
• Services : logique au-dessus des dépôts. Je peux ajouter la mise en cache ici, le filtrage, etc. Mon interface utilisateur communique avec le référentiel par le biais des services, pas directement avec le référentiel. (dépendance un-à-un pour l'interface utilisateur).
• Présentation : Application MVC (à déterminer).

Vous remarquerez que j'ai aussi l'habitude de faire précéder le nom de l'assemblage du projet par le FQN.

J'aime juste son aspect, et dans l'explorateur d'objets, tout a l'air joli et "arborescent".

J'ai également l'habitude de mettre un numéro devant le dossier, afin de le trier en fonction de "ce qui a besoin de quoi". En d'autres termes, tout dépend de la couche métier (elle est donc en haut), le référentiel ne dépend que du métier, les services dépendent du référentiel et du métier, la présentation dépend des services et du métier, etc.

Bien entendu, ce qui précède est un point de départ. Tout ce que j'ai pour l'instant, c'est un référentiel qui renvoie les utilisateurs, et des services qui appliquent une logique par dessus (filtrage).

Finalement, j'aurai d'autres projets commerciaux, d'autres dépôts (un pour chaque zone logique de l'application web), d'autres services (API externes, intégration), et bien sûr, je n'ai rien dans la présentation (je fais du TDD).

J'aime aussi avoir les dépendances en un seul endroit (dossier du projet).

Pour les extensions, j'ai une classe (Extensions.cs) pour chaque projet. En d'autres termes, je suis en train d'"étendre" le référentiel, ou d'"étendre" le service utilisateur, ou d'"étendre" certaines fonctionnalités de l'interface utilisateur.

Pour les projets de test - j'ai un projet de test par projet de solution.

C'est mon avis (pour ce qu'il vaut).

Answer 2

Il est possible de s'améliorer.

Toutes mes solutions ont 4 parties de base. La couche UI, la couche métier, la couche d'accès aux données et les utilitaires. Chaque partie est un projet.

Mon objectif ultime est de ne JAMAIS écrire de code à plusieurs endroits, mais de le réutiliser.

L'interface utilisateur et l'accès aux données sont évidents.

Tout ce qui est spécifique au projet sur lequel je travaille va dans le projet Business.

Les Utilitaires sont ce que j'appelle une bibliothèque commune. Ce sont de bonnes fonctions d'aide que je peux utiliser dans de nombreux projets. Par exemple, une fonction d'aide à la journalisation.

Answer 3

La structure de votre solution/projet me semble assez solide. Si vous n'avez jamais jeté un coup d'oeil à Architecture S#arp vous pouvez le faire. La principale différence entre votre structure et l'architecture de S#arp est que S#arp sépare les contrôleurs, les services et les référentiels en projets distincts. Le principal avantage de cette séparation est qu'il est plus facile d'imposer des limites à vos dépendances (par exemple, vous n'accéderez pas accidentellement à des bibliothèques spécifiques d'accès aux données à partir du code dans Core).

À part cela, votre structure ressemble beaucoup à celle que j'ai tendance à utiliser pour mes projets. J'ajoute également un dossier "Extensions" pour les méthodes d'extension, car il est parfois difficile de leur trouver un bon emplacement.