web-dev-qa-db-fra.com

Une structure de dossiers idéale pour .NET MVC

Lorsque j'ai commencé dans les formulaires Web .NET, je n'ai pas eu beaucoup de mal à trouver une structure de dossiers à suivre, car VS vous offrait des dossiers d'application comme "App_Code" et la plupart des exemples d'applications mettent "BLL", "DAL" à l'intérieur, etc.

Mais maintenant, dans MVC, chaque exemple que je vérifie utilise une structure différente, comme aucune norme cette fois et je n'ai pas trouvé de bonne solution sur Google ou SO.

Donc, nous pouvons peut-être partager la façon dont nous organisons nos projets MVC, peut aider les autres à se faire leur propre opinion. Voici la structure des petits et moyens projets que j'utilise:

App_Data
Areas
    Admin
        Controllers
        Models
        Views
    MyAccount
        Controllers
        Models
        Views
Content
    Images
    Scripts
    Styles
Controllers
    HomeController.cs
Helpers
    ExtensionMethods    // I.e. based on HtmlHelper, use "helper" suffix
        MenuHelper.cs    // to be called as html.Menu()
    Utilities.cs    // Other generic (static) libraries, no suffix used
Models
    ViewModels    // for passing models to Views
        RegisterViewModel.cs    // use "ViewModel" suffix
    Customer.cs    // to extend models like adding Model Validation
Repositories
    CustomerRepository.cs    // use "Repository" suffix
Services
    CustomerService.cs    // use "Service" suffix, to move code away from controllers
Views
    Home
        Index.cshtml
        Register.cshtml
    Shared    // Site Layouts (Master templates), also put partials here
        SiteLayout.cshtml

Qu'en est-il du tien?

asp.net-mvcasp.net-mvc-2asp.net-mvc-3naming-conventionsconventions
35
Nestor

J'ai trouvé qu'il simplifie le déploiement pour que le projet de site Web contienne uniquement du contenu (pas de code compilé).

Quelque chose comme:

projet Web.Site

   Content
      Images
      Css
   Scripts
   Views
   web.config

Et déplacez tout le code compilé dans un autre projet:

projet Web

   Controllers
   Filters
   Models
   ...

Ensuite, vous pouvez traiter tout ce qui se trouve dans le projet Web.Site comme devant être déployé et tous les assemblys requis seront dans Web.Site\bin.

Que vous fassiez un simple déploiement xcopy ou que vous utilisiez WiX pour créer un package MSI, cela vous facilitera un peu la vie.

15
MJ Richardson

J'appuie l'approche des deux projets. Jimmy Bogard a également un Nice post sur l'approche (assurez-vous de parcourir tous les commentaires).

Personnellement, je trouve que lorsque je travaille sur une partie d'une application, j'utilise des services connexes, des contrôleurs, des référentiels, etc. et lorsque vous placez chacun de ces fichiers dans un dossier différent, il peut être fastidieux d'aller et venir et de les trouver . Après avoir joué, j'ai suivi ce format:

AppName.Web.UI 

Scripts
Content
View

AppName.UI.Core 

Attributes
Filters
Formatters
Helpers
Models
  Company
     Interfaces
       IController.cs
       IRepository.cs
       IService.cs
     ViewModels
       ViewModel1.cs
       ViewModel2.cs
     Controller.cs
     Repository.cs
     Service.cs
  User
    ....
Plugins (mailchimp, Twitter OAuth, etc..)
Global.asax (define all the code here rather than in the UI project)

Projet de test 

  ...

Je pense que cela dépend de la taille de votre projet pour savoir si vous décomposez et utilisez les sous-dossiers Interface et ViewModel. Ce n'est pas parfait, mais j'ai trouvé qu'il correspond mieux à ma façon de penser.

Il est également possible de placer vos services et référentiels dans un troisième projet (AppName.Core), en laissant le projet AppName.Web.Core encapsulant uniquement les parties liées au Web (Attributs, Contrôleurs. ViewModels, etc.). Encore une fois, cela se rapporte vraiment à la complexité du projet.

6
TheRightChoyce

Tant qu'il est clair où se trouvent les choses, peu importe. Je pense que c'est juste une question de cohérence au sein de votre organisation/groupe.

5
dreadwail