我正在尝试根据不同的标准缓存导航菜单的各个部分。
例如，新闻和文章需要在持续时间内刷新，而登录和个人资料应该基于每个用户进行缓存。
我正在考虑两种选择 - 是否有人能够开诚布公地了解每种选择的优点/缺点？如果可能的话，建议采取更好的方法！
选项1。
只需将所有必需的html缓存为数据缓存中的字符串。必要时手动检查用户差异。
我（可能是错误的）想象这将是最需要实现的工作，但也是缓存不同部分的最有效方式。
选项2。
为菜单的每个部分设置一个具有不同子操作的NavigationController。 （我们可以根据需要对每个子操作应用不同的outputCacheProfile。）
但这需要我们为导航菜单的每个部分调用单独的RenderAction。我对此感到担心，因为对Phil Haack的一篇博文发表了评论：
[渲染动作]与我们发出另一个请求非常相似 需要运行路由以确保我们有适当的路由 调用action方法的数据和上下文。所以每次打电话给 RenderAction将加起来。
这里的完整帖子：http://haacked.com/archive/2009/11/18/aspnetmvc2-render-action.aspx
答案 0 :(得分：5)
我认为这个问题得到了普遍回避，因为这里没有正确答案。
事实上，您选择架构来实施复杂导航将决定最佳缓存策略。
我非常偏向通过带有子操作的部分视图进行导航。
我同意你的看法，引用文件更有意义。我更喜欢让数据库条目包含按键分组的导航选项，并通过参数引用到子操作。
所以你的导航表可能看起来像这样
grpId Title Path
1 Home Page /
1 About Page /Home/About
1 Reports Page /Reports
2 Home Page /
2 Admin Page /Admin
2 Reports Page /Reports
并且您的孩子的行动将会受到影响
[OutputCache(Duration = 60000, VaryByParam = "grpId")]
public PartialViewResult NavigationPage(int grpId)
可以提取所有导航组选项并渲染自定义导航菜单。这种形式的输出缓存是按时间（60000秒和您的参数）自定义的
<强>结论：
我怀疑我没有告诉你什么新内容，但只确认了你已经倾向于什么。 MVC框架非常强大，并提供了很好地处理您想要做的工具。使用文件和数据缓存也是一种有效的方法，但它可能会让您更加头疼，并且需要您自己实施。
请记住： Haacks的帖子已超过4年（ MVC 2 Beta ）。从那时起，框架和输出缓存已经很好地发展。您现在可以缓存部分，而无需担心缓存整个页面。 This recent reference to caching with MVC 4并没有直接反对菲尔先前的担忧，但显然忽略了它们。