asp.net-mvc - 允许并行性和效率的 Asp.net MVC 页面构建的最佳实践是什么？

Question

我发现在对 ASP.net MVC 的页面组合框架的批评中很难与任何东西争论。

http://www.matlus.com/problems-with-asp-net-mvc-framework-design/

特别是这几点:

无权访问 View 或部分 View 实例

ViewData 是您的松散类型信息载体

Controller 并没有真正控制

子操作对请求上下文没有意义

View 耦合到 Controller

对于小型应用程序，我不认为其中很多被证明是一个很大的问题，但在大型应用程序中，您希望重用大量共享组件，或者即使您只有一个依赖于多个共享组件的大型应用程序后端信息源获取呈现 View 所需的所有信息时，它开始崩溃。

已经针对这些问题提出了各种半解决方案，但它们似乎不能很好地扩展或具有不合需要的设计约束。

下面是一个示例应用场景:

50% 的页面内容在应用程序中的所有页面(页眉、页脚、菜单等)中是通用的

您的应用程序实际上可能由多个区域组成，每个区域都有自己的 Controller 等，用于独立开发。

公共(public)页面内容中的许多页面元素(菜单、页面标题信息、页脚、披露)需要一个或多个服务调用来填充数据以进行呈现。

好的，那么在 asp.net mvc3 中，假设您决定共享一个包含 50% 通用 UI 标记的通用 Razor 布局。这有助于关注点分离，因为应用程序开发人员不需要关注常见的 ui，并且可以专注于特定于其专业领域的逻辑和 View 。

但是，如果此共享布局需要数据(一种或多种模型类型的某种外观)来完全呈现自身，则这完全失效。页面上可能有独立的元素，每个元素都需要特定的数据模型，例如:
* 主菜单模型
* 二级菜单模型
* 页脚链接模型
* 授权模式
* 页脚免责声明模型

这些模型中的每一个都可能有不同的来源。因此，虽然您可以共享模板，但没有一种简单的方法来共享构建每个模型的逻辑——而且绝对没有我见过的通用、可扩展和高性能的模型。

我见过的解决这个问题的一些方法是:

强类型化公共(public)布局，这要求所有 View 模型子类化一个公共(public)基模型类。 (但是没有通用的解决方案来填充这样的元模型，这在设计上是有限制的，使得模型变得庞大且难以测试)此外，模型填充仍然落入每个 Controller ，违反了关注点分离和单一职责原则和除了特定于 View 的模型信息外，还通过堆积大量额外的逻辑来填充元模型，从而使单元测试 Controller 变得复杂。

保持公共(public)布局无类型，因此您不必从公共(public)基本模型继承，但这需要您使用 ViewData 或 ViewBag 来传达模板所需的所有不同模型，因此您失去了强大的类型化优势并最终松散的数据契约。您仍然存在缺乏填充元模型的通用解决方案以及随之而来的所有问题的问题。

每个 Controller 都必须继承一个通用的基本 Controller 类来支持通用的布局和模型。构建元模型的公共(public)方面的逻辑在这里。但这并不总是理想的架构或设计约束。这至少解决了关注点分离问题。

代替元模型，在公共(public)布局中通过 RenderAction() 使用子操作来制作可重用的“portlet”样式小部件，每个小部件都独立知道如何构建其数据模型并将其提供给 View 。这对于关注点分离非常有用，但也有其自身的缺点: View 在渲染期间通过子 Action 有效地进行服务调用，子 Action 完全不知道原始请求上下文，违反了 DRY 原则，因为每个子 Action 都不知道在它之前发生了什么，所以每个人都可以在同一个 http 请求中一遍又一遍地调用相同的服务，等等。想象一个页面的 20-30 个元素都需要独立调用 RenderAction()...

还有其他情况(一些也在 stackoverflow 上看到)，其中 RenderAction() 作为解决方案存在其他问题。例如在循环中发出多个 RenderAction() 调用会导致所有这些 Controller 方法的串行执行这一事实。 RenderAction() 没有并行的机会。每个子 Controller 操作中的 I/O 绑定(bind)服务调用导致整个渲染过程等待 I/O。 Controller 只知道它的直接 View 和模型，并且没有任何东西可以完整地了解 View 内部的内容以便并行化某些操作。

上述评论的作者在 ASP.Net mvc 之上开发了一个不同的 UI 模型，称为 Quartz，它允许上帝 Controller 对 View 有深入的了解，并且可以为每个 View 提供一个 View 模型，因此有机会并行化服务调用构建这些 View 模型的中心位置。我不知道这是否是提供钩子(Hook)来克服问题的最佳设计，但看起来很有希望。

我的问题是，在 ASP.Net MVC 之上构建复杂应用程序以干净地解决这些问题的最佳实践是什么？我已经想到了几种可能性(尽管在 ASP.Net MVC 中没有一种可能是实用的——即 TBD)，但其他人肯定已经遇到过这种情况。 ASP.Net MVC 中的设计模式是什么，或者可能使这个问题变得容易处理的问题是什么？

Answer 1

我个人认为通过RenderAction使用Child Actions的优点大于缺点。

您可以创建“小部件”类型的元素，并将它们的逻辑包装在 Controller Action 中 - 这样调用小部件的 View 可以保持对子 Action 正在做什么以及它是如何做的一无所知 - 导致很好的分离的担忧。

您已经详细说明了这种方法的缺点，但是我认为可以通过合理的缓存策略将负面影响降至最低。