我一直对我认为自相矛盾的术语感到困惑：ASP.NET MVC 声称正在推进和支持“关注点分离”的座右铭，我觉得这是个好主意。
但是，似乎没有办法将控制器、模型或视图分离到它们自己的程序集中，或者将区域分离为程序集。
使用 ASP.NET MVC 中固定的 Controller、Model 和 View 文件夹，您实际上是在创建一个大杂烩。这真的是关注点分离吗？好像跟我完全相反。
所以我想知道的是：
如何创建一个 ASP.NET MVC 解决方案，将控制器、模型和充满视图的文件夹分离到单独的程序集中？
如何将 ASP.NET MVC 2 的区域放入单独的程序集中？
或者您如何管理一个大型 ASP.NET MVC 应用程序 - 它有几十个甚至超过一百个控制器、大量模型和视图模型类以及数百个视图？
【问题讨论】：
标签： asp.net-mvc separation-of-concerns
我认为您正在寻找Areas in ASP.Net MVC 2。 CSProj 文件中有一些需要取消注释的内容，但之后它会在您构建时复制视图。我认为没有任何要求 Controller 或 Model 类与视图在同一个程序集中。
Walkthrough: Creating an ASP.NET MVC Areas Application Using Multiple Projects
【讨论】：
控制器： AFAIK 你不应该做任何特别的事情来将控制器放入他们自己的程序集中。至多你所要做的就是覆盖你的 ControllerFactory 的 GetControllerType 方法。
模型：对模型放置位置的零限制。尽管这令人不悦，但我经常使用来自 Nhibernate/其他 ORM 层或 WCF/服务层 DTO 的持久对象，它们位于单独的程序集中作为我的视图。这与使用 WebForms 的方式相同。
视图：必须将单独程序集中的视图标记为嵌入资源，然后您必须使用知道如何从资源而不是文件系统获取视图的自定义VirtualPathProvider。 views from an resource instead of the file system。这又是您用于 WebForm 开发的完全相同的技术。
关于 mcintyre321 和他的 Portable Areas 回答： 链接的项目几乎不做任何定制，只是简单地将现有的 MVC 2 扩展点包装成更易于使用的抽象。它几乎没有“自定义”和更多的语法糖。
您管理大型 MVC 应用程序就像管理任何其他大型应用程序一样。我害怕打开一个 500 页的 WebForms 项目，因为你永远不知道每个代码背后的内容。使用 MVC，不同的功能大部分都在其正确的位置。一点也不矛盾。
【讨论】：
将代码分成单独的程序集与关注点分离是正交的。代码所在的位置不是“问题”。关注点分离与各个组件的职责和依赖方向有关。例如，视图负责渲染输出，控制器知道视图，但视图并不真正了解控制器。
同样，模型对视图或控制器一无所知，但视图和控制器都会知道模型。
但是，回到你的问题。正如 jfar 所指出的，将控制器和模型移动到另一个组件中非常容易并且会起作用。将视图移动到另一个程序集中比较棘手。具有自定义虚拟路径提供程序的嵌入式资源是一种方法，但我们通常不推荐用于高性能站点的方法。但是，如果它满足您的需求，那就去吧。
【讨论】：
MVC 具有很强的可扩展性，不需要遵守 Controller、View 和 Model 文件夹结构。您可以将控制器放置在您想要的任何位置，但是如果它们位于另一个组件中，您将需要实现自己的控制器工厂，该工厂知道如何定位它们。 Here 是使用 Windsor 定位控制器的示例。
您的模型/视图模型可以在您想要的任何地方。您只需要在 web.config 中引用它们的命名空间，以便视图知道在哪里查找。 （至少我知道 Spark 视图引擎是这样的。）
您将您的观点放在任何网络项目中。我通常的策略是创建一个包含views 文件夹的普通Web（非mvc）项目。 （这甚至可能是一个遗留的网络应用程序！）然后我所有的控制器都放在一个单独的类库中。我的视图模型和服务放在另一个地方。
就构建文件夹而言，我通常以域概念为中心。我会在每个项目中为用户、产品、订单等创建一个文件夹。我在任何地方都没有 Models 或 Controllers 文件夹。
【讨论】：