.NET MVC 的理想文件夹结构

37

在我刚开始学习.NET Webforms时,我没有太多麻烦来寻找一个文件夹结构,因为VS提供了应用程序文件夹(例如“App_Code”),而大多数应用程序示例将“BLL”、“DAL”放在其中等等。

但是现在,在MVC中,我检查的每个示例都使用不同的结构,似乎没有标准化,我在Google或SO上也没有找到好的解决方案。

因此,也许我们可以分享如何组织我们的MVC项目,这可能有助于其他人自己形成想法。以下是我用于小到中型项目的结构:

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

你的情况怎样?


可能是新手问题:虽然我已经使用ASP.NET MVC很长时间了,但我从来没有遇到过.cshtml!那是什么? :) - Maxim Zaslavsky
1
是的,那就是Razor,MVC3上新的默认视图引擎,更加简洁,使代码更易读。你可以查看Scott Gu的博客:http://weblogs.asp.net/scottgu/archive/2010/07/02/introducing-razor.aspx - Nestor
似乎这篇文章在搜索“mvc 4文件夹结构”时排名第一,但问题和答案可能已经过时。Asp.Net MVC通常需要非常严格的目录结构。有人知道理想树的任何更新吗? - bob-the-destroyer
你可能没有找到“理想的树”的原因就是我发布这篇文章的原因:并不存在一个完美的树,所以我建议我们分享自己的经验。每个人迟早都会采用自己的方式。我认为更重要的是在MVC需要遵循约定(如保留像Controllers、Views这样的文件夹)的基础上,采用通用的标准(如Models、Services文件夹),然后加入自己的特色(例如,我现在将解决方案分成像MyApp.Core、MyApp.Web、MyApp.Localization这样的项目)。 - Nestor
4
为什么我的问题(http://stackoverflow.com/questions/14623056/good-naming-convention-for-classes-associated-with-an-mvc-app-directory)基本上与这个问题相同,但我的问题被关闭为“不具建设性”,而这个问题没有? - Jez
3个回答

15

我发现将网站项目仅包含内容(无编译代码)可以简化部署。

例如:

Web.Site 项目

   Content
      Images
      Css
   Scripts
   Views
   web.config

将所有已编译代码移动到另一个项目中:

Web 项目

   Controllers
   Filters
   Models
   ...

然后,您可以将Web.Site项目内的所有内容视为需要部署的内容,并且所有必需的程序集都将在Web.Site\bin中。

无论您是进行简单的xcopy部署还是使用WiX构建MSI包,这都会使生活变得更加轻松。


2
我赞同这个观点。我的项目通常使用“Web”项目和“Web.Components”项目进行组织。“Web”项目中几乎没有什么代码,而“Web.Components”则包括所有控制器和过滤器等内容。最后,我有一个“Core”项目,其中包含我的模型。 - Nathan Taylor
非常有趣,是的,我也喜欢,我会考虑在我的项目中使用。谢谢分享。 - Nestor

6
我赞同采用两个项目的方法。Jimmy Bogard也对此有一篇很好的文章(请确保阅读所有评论)。
我个人发现,当我在应用程序的某个部分工作时,我使用相关的服务、控制器、存储库等。当你把这些文件放在不同的文件夹中时,来回找它们会变得很繁琐。经过一些尝试后,我遵循以下格式:

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)

测试项目

  ...

我认为是否需要进一步拆分并使用接口和ViewModel子文件夹取决于您的项目规模。虽然不是完美的,但我发现它与我的思考方式更加契合。
还可以将服务和存储库放入第三个项目(AppName.Core),使AppName.Web.Core项目仅封装Web相关部分(属性、控制器、ViewModel等)。同样,这确实与项目的复杂程度有关。

我阅读了你提到的帖子,我对这个结构有一个问题,如何在区域中使用?因为区域有它们自己的模型、控制器、视图,而区域控制器与根目录下的控制器不同,那么如何使用 IU,Core 来划分呢? - Nestor
我个人并没有深入使用区域,但你应该能够以类似的方式逻辑地分解它们。我会将区域添加到 UI 项目中,然后将相关控制器移动到核心项目中。只要命名空间保持相同,物理项目结构就不重要了。或者,根据您希望不同区域在不同项目中可重用的情况,您可以为每个区域仅有一个项目,并在主项目中引用它们...这取决于您对不同区域的目标是什么。 - TheRightChoyce
Bogard先生似乎不再偏爱两个项目的方法。大约一年前,他在您提到的帖子中撰写了一条评论,表示:“抱歉,这篇文章已经非常陈旧和过时了。只需创建一个项目,不要创建两个项目。” - Theophilus

5
只要事物的位置清晰明了,就不太重要了。我认为这只是在组织/团体内保持一致性的问题。

3
我知道,但通常在开始“批量生产”网站之前,您希望制定自己的标准,并且您希望感觉到您的标准是您能想出的最好的。由于很少有一致的例子,我花了几乎整天的时间来想出这个,所以也许我们可以通过分享我们的“建议性”结构来节省其他人的时间。 - Nestor
你对这个有什么看法?http://www.dotnetexpertguide.com/2012/01/dividing-mvc-components-in-separate.html - user20358

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接