asp.net-mvc - ASP.NET MVC - 分离大型应用程序

Question

我一直对我认为自相矛盾的术语感到困惑：ASP.NET MVC 声称正在推进和支持“关注点分离”的座右铭，我觉得这是个好主意。

然而，似乎没有办法将控制器、模型或视图分离到它们自己的程序集中，或者将区域分离为程序集。

使用 ASP.NET MVC 中的 fixedController和文件夹Model，View您实际上是在创建一个大杂烩。这真的是关注点分离吗？似乎与我完全相反。

所以我想知道的是：

score 8 · Accepted Answer

控制器： AFAIK 你不应该做任何特别的事情来将控制器放入他们自己的程序集中。您最多需要做的就是覆盖 ControllerFactory 的 GetControllerType 方法。

模型：对模型放置位置的零限制。尽管这令人不悦，但我经常使用来自 Nhibernate/其他 ORM 层或 WCF/服务层 DTO 的持久对象，它们位于单独的程序集中作为我的视图。这与使用 WebForms 的方式相同。

视图：必须将单独程序集中的视图标记为嵌入式资源，然后您必须使用知道如何从资源而不是文件系统获取视图的自定义VirtualPathProvider 。来自资源而不是文件系统的视图。同样，这与您将用于 WebForm 开发的技术完全相同。

关于 mcintyre321 和他的 Portable Areas 回答： 链接的项目几乎不做任何定制，只是简单地将现有的 MVC 2 扩展点包装成更易于使用的抽象。它几乎没有“定制”和更多的语法糖。

您管理大型 MVC 应用程序就像管理任何其他大型应用程序一样。我害怕打开一个 500 页的 WebForms 项目，因为你永远不知道每个代码背后的内容。使用 MVC，不同的功能大部分都在其正确的位置。它一点也不相反。

score 8 · Accepted Answer

我认为您正在寻找ASP.Net MVC 2 中的区域。CSProj 文件中有一些需要取消注释的内容，但之后它会在您构建时复制视图。我认为没有要求ControllerorModel类与视图在同一个程序集中。

score 6 · Accepted Answer

将代码分成单独的程序集与关注点分离是正交的。代码所在的位置不是“问题”。关注点分离与各个组件的职责和依赖方向有关。例如，视图负责渲染输出，控制器知道视图，但视图并不真正了解控制器。

同样，模型对视图或控制器一无所知，但视图和控制器都会知道模型。

但是，回到你的问题。正如 jfar 所指出的，将控制器和模型移动到另一个组件中非常容易并且会起作用。将视图移动到另一个程序集中比较棘手。具有自定义虚拟路径提供程序的嵌入式资源是一种方法，但我们通常不推荐用于高性能站点的方法。但是，如果它满足您的需求，那就去吧。

score 1 · Accepted Answer

MVC 具有很强的可扩展性，不需要遵守 Controller、View 和 Model 文件夹结构。您可以将控制器放置在您想要的任何位置，但是如果它们位于另一个组件中，您将需要实现自己的控制器工厂，该工厂知道如何定位它们。这是使用 Windsor 定位控制器的示例。

您的模型/视图模型可以在您想要的任何地方。您只需要在 web.config 中引用它们的命名空间，以便视图知道在哪里查找。（至少我知道 Spark 视图引擎是这样的。）

你把你的观点放在任何网络项目中。我通常的策略是创建一个包含views 文件夹的普通Web（非mvc）项目。（这甚至可能是一个遗留的网络应用程序！）然后我所有的控制器都放在一个单独的类库中。我的视图模型和服务进入另一个。

至于结构化文件夹，我通常将我的层次结构集中在域概念上。我会在每个项目中为用户、产品、订单等创建一个文件夹。我在任何地方都没有 Models 或 Controllers 文件夹。

score 0 · Accepted Answer

5 回答 5