.NET MVC 的理想文件夹结构答案

【问题标题】：An Ideal Folder Structure for .NET MVC [closed].NET MVC 的理想文件夹结构
【发布时间】：2011-05-03 22:44:25
【问题描述】：

当我开始使用 .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！那是什么？ :)
是的，就是剃刀，MVC3 上新的默认视图引擎，更干净，代码更易读，可以查看 Scott Gu 的博客：weblogs.asp.net/scottgu/archive/2010/07/02/…
看来这篇文章首先出现在搜索“mvc 4 文件夹结构”时，但问题和答案可能已经过时了。 Asp.Net MVC 通常需要非常严格的目录结构。有人知道理想树的任何更新吗？
你可能没有找到“理想树”的原因是我发布这个的原因：没有理想的树，所以我建议我们分享我们的。每个人迟早都会采用自己的一种。我认为更多的是在 MVC 对约定的需求（保留控制器、视图等文件夹）、采用普遍接受的标准（模型、服务的文件夹）以及添加自己的风格（我现在在项目中拆分解决方案，如MyApp.Core、MyApp.Web、MyApp.Localization）。
为什么my question 与此基本相同被关闭为“非建设性”，而这个没有？

标签： asp.net-mvc asp.net-mvc-2 asp.net-mvc-3 naming-conventions conventions

【解决方案1】：

我发现让网站项目只包含内容（不包含编译代码）可以简化部署。

类似：

网站项目

   Content
      Images
      Css
   Scripts
   Views
   web.config

并将所有编译后的代码移到另一个项目中：

网络项目

   Controllers
   Filters
   Models
   ...

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

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

【讨论】：

我支持这个。我的项目通常由一个“Web”项目组织，然后是一个“Web.Components”项目。 “Web”项目中的代码很少，而“Web.Components”包含所有东西，如控制器和过滤器。最后，我有一个包含我的模型的“核心”项目。
很有趣，是的，我也喜欢，我会在自己的项目中考虑。感谢分享。

【解决方案2】：

我支持两个项目的方法。 Jimmy Bogard 也有一个nice post on the approach（确保通过所有 cmets）。

我个人发现，当我在处理应用程序的一部分时，我会使用相关的服务、控制器、存储库等。当您将这些文件中的每一个放在不同的文件夹中时，来回走动可能会很乏味并找到它们。在玩了一些之后，我一直遵循这种格式：

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)

测试项目

...

我认为这取决于您是否进一步分解并使用 Interface 和 ViewModel 子文件夹，这取决于您的项目有多大。它并不完美，但我发现它更符合我的想法。

也可以将您的服务和存储库放入第三个项目 (AppName.Core)，让 AppName.Web.Core 项目仅封装 Web 相关部分（属性、控制器、视图模型等）。同样，这确实与项目的复杂性有关。

【讨论】：

我读了你提到的帖子，我对这个结构有一个问题，如何与区域一起使用？因为Areas有自己的Models、Controllers、Views，而且Area controllers和Controllers在根上是不同的，那么如何使用IU、Core来划分呢？
我个人并没有过多地使用区域，但是您应该能够以类似的方式在逻辑上将它们分解。我将该区域添加到 UI 项目，然后将相关控制器移动到核心项目。只要名称空间保持不变，物理项目结构就无关紧要。或者，根据您是否希望您的区域可在不同项目中重复使用，您可以为每个区域创建一个项目并在您的主项目中引用它们.. 真的取决于您对不同区域的目标是什么。
先生。 Bogard 似乎不再支持两个项目的方法。大约一年前，他在你提到的post 上写了一条评论，上面写着：“抱歉，这篇文章已经过时了。只做一个项目，不要创建两个项目。”

【解决方案3】：

只要清楚事物在哪里，这并不重要。我认为这只是在您的组织/组内保持一致的问题。

【讨论】：

我知道，但通常您想在开始“连续生产”网站之前制定标准，并且您希望自己的标准是您能想到的最佳标准。因为很少有一致的例子，我花了几乎一整天的时间来提出这个，所以也许我们可以通过分享我们的“建议”结构来节省其他人的时间。
您对此有何看法？ dotnetexpertguide.com/2012/01/…