根据Brad Wilson的说法，RenderAction 比RenderPartial慢。
但是，有没有人有任何显示性能差异的统计数据？
我正在开发一个应用程序，其中页面由“窗口小部件”组成。
我有两个选择：
观看级别的构图
为每个小部件调用RenderAction。这是迄今为止最简单的方法，但这意味着我们正在为每个小部件执行完整的MVC循环。
控制器级别的构成
为包含每个小部件所需数据的页面编写一个ViewModel。为每个小部件调用RenderPartial。这实现起来要复杂得多，但这意味着我们只会制作一个MVC周期。
我在页面上用3个不同的小部件测试了上述方法，渲染时间的差异是十分之一秒（几乎不值得担心）。
但是，有没有人比任何测试结果更具体，或者尝试两种方法？
答案 0 :(得分：4)
我最近处理过一个遇到性能问题的应用程序，发现一个视图正在对RenderAction进行四次调用，另外一次调用布局。我发现每次调用RenderAction - 即使我添加了一个返回空视图的虚拟动作 - 大概需要200-300ms（在我的本地机器上）。乘以调用次数，您在页面上获得了巨大的性能。在我的情况下，有四个调用导致大约一秒不必要的服务器端开销。相比之下，对RenderPartial的调用大约是0-10ms。
我会尽可能避免使用RenderAction来支持RenderPartial。控制器应负责返回所有必要的信息。对于小部件，如果您需要多个小部件的多个操作，我会尝试将它们组合成一个动作，因此RenderAction开销只发生一次，但如果您的网站充分执行，我会将它们分开以实现更清洁的设计。
编辑：我使用MiniProfiler收集了此信息并点击了该网站。它不是非常准确，但它确实显示了差异。
编辑：正如Oskar在下面指出的那样，有问题的应用程序可能会为global.asax中的每个请求运行一些密集的代码。此命中的大小取决于应用程序代码，但RenderPartial将完全避免执行另一个MVC循环。
答案 1 :(得分：3)
我建议另外两个选项，都需要在Controller级别组合视图模型，两者都可以一起工作（取决于数据）
如果你想将这些小部件保存在不同的程序集中，选项2的效果非常好，毕竟它们只是返回字符串的函数。我认为它也有最好的表现，但当然你失去了“设计师友好”的模板。我认为考虑可维护性方面很重要，不仅仅是原始性能（直到你真正需要它，即使这样，缓存也会更有帮助）。
对于小东西（日期或名称格式化等）我会使用助手，因为html通常是带有类的跨度，对于更复杂的东西我会使用显示模板。