7

根据 Brad Wilson 的说法，RenderAction比RenderPartial 慢。

但是，有没有人得到任何显示性能差异的统计数据？

我正在开发一个页面由“小部件”组成的应用程序。

我有两个选择：

视图级别的合成

为每个小部件调用 RenderAction。这是迄今为止最简单的方法，但确实意味着我们正在为每个小部件执行完整的 MVC 循环。

控制器级别的组合

为包含每个小部件所需数据的页面编写一个 ViewModel。为每个小部件调用 RenderPartial。这实现起来要复杂得多，但确实意味着我们只会创建一个 MVC 循环。

我在一个页面上使用 3 个不同的小部件测试了上述方法，渲染时间的差异为 10 分之一秒（几乎不值得担心）。

但是，有没有人得到比这更具体的测试结果，或者可能有尝试两种方法的经验？

4

2 回答 2

5

我最近处理了一个遇到性能问题的应用程序，并发现一个视图正在对 RenderAction 进行四次调用，另外还有一个在布局中。我发现每次调用 RenderAction——即使我添加了一个返回空视图的虚拟操作——也需要大约 200-300 毫秒（在我的本地机器上）。乘以调用次数，您会在页面上获得巨大的性能影响。在我的例子中，有四个调用导致大约一秒钟的不必要的服务器端开销。相比之下，对 RenderPartial 的调用大约为 0-10 毫秒。

我会尽可能避免使用 RenderAction 来支持 RenderPartial。控制器应负责返回所有必要的信息。在小部件的情况下，如果您需要多个小部件的多个操作，我会尝试将它们组合成一个操作，这样 RenderAction 开销只会发生一次，但如果您的站点运行良好，我会将它们分开以实现更简洁的设计。

编辑：我使用 MiniProfiler 收集了这些信息并点击了该站点。它不是超级准确，但它确实清楚地显示了差异。

编辑：正如奥斯卡在下面指出的那样，有问题的应用程序可能有一些密集的代码，为 global.asax 中的每个请求运行。此命中的大小取决于应用程序代码，但 RenderPartial 将完全避免执行另一个 MVC 循环。

于 2012-08-16T15:00:49.997 回答
4

我建议另外 2 个选项，都需要在控制器级别组合视图模型，并且两者都可以一起工作（取决于数据）

  1. Html.DisplayFor() - 显示模板
  2. 通过扩展方法的助手

如果您想将这些小部件保存在不同的程序集中，选项 2 效果很好，毕竟它们只是返回字符串的函数。我认为它也有最好的性能，但当然你失去了“设计师友好”的模板。我认为考虑可维护性方面很重要，而不仅仅是原始性能（直到您真正需要它，即使那样，缓存也更有帮助）。

对于小东西（日期或名称格式等）我会使用助手，因为 html 通常是一个带有类的跨度，对于更复杂的东西我会使用显示模板。

于 2012-06-27T15:01:42.930 回答