我目前正在调查将MVC合并到现有WebForms框架中的可能性。目前我们有像ThreadsModules和CreateMessageModule这样的“模块”的概念。这些模块只是UserControls，由框架加载到页面上。在回发时，ASP.NET WebForms会解析_EVENTTARGET和_EVENTARGUMENT字段并引发相应的事件处理程序（就像任何其他webforms页面一样）。
但是，在MVC中，没有控件，也没有回发。那么问题是那里有什么？模型 - 视图 - 控制器的概念到处讨论特定页面，但我需要模块。所以我想让模块由模型 - 局部视图 - 控制器组成，并创建一个MasterController，它将解析请求并调用相应模块的控制器。
然而，采用这种方法仍然存在将不同控制器集成到一个页面中的问题。例如，在页面上，我有包含网格的ThreadsModule。网格需要排序和分页，因此它需要自己的控制器。所以在那里我将有2个嵌套表单，每当我点击网格中的“排序”按钮时它们都会提交。显然我可以让ThreadsModule控制器处理网格的排序。但这意味着我必须使每个其他具有网格的模块知道如何排序。很多冗余和低效率。
基本上，主要问题是如何封装可以跨控制器重用的复杂逻辑？
UPD ：让我再举一个场景。您有一个包含多个表单的页面。表单发布到不同的目标，可能在不同的控制器上。在任何特定表单提交请求后，用户以何种方式停留在同一页面上？同样，它对封装和重用逻辑很有用。
答案 0 :(得分：3)
在我看来，你正试图将创建的概念用于解决WebForms对MVC的特定要求。
我建议您不要尝试将WebForms架构应用于MVC。这真的是它自己的哲学和做事方式。仅仅因为在WebForms中运行良好并不意味着它必须在MVC中以相同的方式工作。
您的架构听起来设计不佳，并在用户控件中添加了许多业务逻辑。这不是在MVC中做事的方法。相反，您应该将这些控件重构为控制器可以调用的“服务”。
编辑：
重要的是要记住MVC是一个表示架构，而不是整个应用程序架构。 MVC仅关注如何向用户呈现信息以及如何捕获他们的输入。所有业务规则，计算，逻辑都应该发生在与控制器或视图无关的业务对象中，并且只与模型模糊相关。
您可以完全控制已提升的输出。如果要使用具有不同目标的多个表单，则可以执行此操作。只需将动作设置为您想要的任何动作即可