La structure de solution ultime de Visual Studio

Réalisant que cela pourrait être subjectif sur la base du projet en cours, je recherche la méthode des “meilleures pratiques” pour structurer une solution VS (Visual Studio).

N’hésitez pas à le modifier, à commenter ce que vous pensez être incorrect, à suggérer des alternatives, etc. J’adorerais voir ce wiki communautaire devenir une excellente ressource pour les personnes qui commencent avec VS Solutions.

Voici ci-dessous ce que j’ai travaillé pour moi (sur mon projet actuel), mais je sais pertinemment qu’il y a des trucs au mauvais endroit. Dans mon scénario, je construis une application Web à l’ aide de MVC 2

S’il vous plaît, postez votre idée de la structure de solution ultime pour que nous puissions avoir une idée de la “meilleure façon” / “meilleure pratique” (peu importe ce que cela signifie exactement )

C’EST À DIRE:
Comment divisez-vous votre couche DAL (Data-Access-Layer) / BLL (Business-Logic-Layer)?
Mettez-vous votre couche de référentiel et votre couche de service dans votre BLL? Si vous utilisez MVC (Model-View-Controller), conservez-vous vos contrôleurs dans l’interface utilisateur plutôt que dans le Core?
Jetez-vous beaucoup de choses dans vos dossiers Utility / Miscellaneous ou les séparez-vous encore plus?
etc…


  • MySolution
    • MySolution.Core
      • Authentification
        • c’est là que j’ai un POCO et une méthode pour Searialize le poco dans la section userData du cookie d’authentification
      • Base
        • voici où je garde mon BaseController et par BaseGlobal
      • Contrôleurs
        • tous mes contrôleurs (évidemment)
      • Domaine
        • DatabaseModels
          • contient mon fichier L2S .dbml
        • JsonModels
          • modèles utilisés pour transmettre des objects JSON à la fenêtre
        • Référentiels
        • Prestations de service
        • ViewModels
      • Les extensions
        • toutes les méthodes d’extension
      • Des filtres
        • Filtres d’action
      • Utilitaires
        • Apis
          • tout le code API tiers entre ici
        • Badges
          • le calcul du badge va ici
        • MailClient
          • envoyer un message texte ou HTML en utilisant les classes ici
        • RoutingHelpers
          • contient une classe pour activer les itinéraires en minuscules
        • contient également des choses que je ne sais pas où placer … IE: HTMLSanitizer, HtmlHelpers personnalisés, aide UserInfo (adresse IP, navigateur, etc.), DataConverter, etc.
    • MySolution.UI
      • App_Browsers
      • Les atouts
        • Css
        • Images
        • Scripts
      • Des vues
      • Global.asaxhérite de BaseGlobal
      • Web.config

Captures d’écran
CoeurInterface utilisateur

S’il vous plaît n’hésitez pas à commenter en conséquence, ou mieux encore, postez votre propre version (réponse) ci-dessous. Je sais que ce que j’ai n’est pas la meilleure façon.

Votre structure de solution / projet me semble bien. Si vous n’avez jamais regardé S # arp Architecture , vous pouvez le faire. La principale différence entre votre structure et l’architecture de S # arp est que S # arp répartit les contrôleurs, services et référentiels dans des projets distincts. Le principal avantage de ceci est qu’il devient plus facile d’imposer des limites à vos dépendances (par exemple, vous n’accéderez pas accidentellement aux bibliothèques spécifiques d’access aux données à partir du code dans Core).

En dehors de 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 celles-ci sont parfois difficiles à trouver.

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

texte alt

Dans ma solution:

  • Business: logique spécifique au domaine / projet, et plus particulièrement aux POCO.
  • Données: référentiels. auto explicatif.
  • Services: logique sur les référentiels. Je peux append la mise en cache ici, filtrer, etc. Mon interface utilisateur communique avec le référentiel via Services, pas directement vers le référentiel. (dépendance individuelle pour l’IU).
  • Présentation: application MVC (TBD).

Vous remarquerez que j’ai aussi l’habitude de préfixer le nom de l’assemblage du projet avec le nom de domaine complet.

J’aime simplement son aspect, et dans l’Explorateur d’objects, tout a l’air sympa et “arboré”.

Aussi, j’ai l’habitude de mettre un numéro devant le dossier, de sorte qu’il sortinge en fonction de “ce qui a besoin de quoi”. En d’autres termes, tout dépend de la couche métier (donc du haut), le référentiel ne dépend que de l’entreprise, les services dépendent du référentiel et de l’entreprise, la présentation dépend des services et de l’entreprise, etc.

Bien sûr, ce qui précède est un sharepoint départ. Tout ce que j’ai maintenant, c’est un repository qui renvoie les utilisateurs et les services qui appliquent la logique dessus (filtrage).

Finalement, j’aurai plus de projets d’entreprise, plus de repositorys (un pour chaque domaine logique de l’application Web), plus de services (API externes, intégration) et, bien sûr, je n’ai rien dans Presentation (im TDD).

J’aime aussi avoir les dépendances au même endroit (dossier de projet).

Pour les extensions, j’ai une classe (Extensions.cs) pour chaque projet. En d’autres termes, je “étends” le référentiel, ou “Extension” du service utilisateur, ou “Extension” de certaines fonctionnalités de l’interface utilisateur.

Pour les projets de test, j’ai un projet de test par projet de solution.

C’est mes deux cents (pour ce que ça vaut).

Il y a place à amélioration.

Toutes mes solutions comportent 4 parties de base. La couche d’interface utilisateur, la couche métier, la couche d’access aux données et les utilitaires. Chaque partie est un projet.

Mon but ultime est de ne JAMAIS écrire de code dans plus d’un endroit mais de le réutiliser.

L’interface utilisateur et l’access aux données sont évidents.

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

Les utilitaires sont ce que j’appelle une bibliothèque commune. Ce sont des fonctions utiles que je peux utiliser dans de nombreux projets. Par exemple une fonction pour faciliter la journalisation.