所以我正在创建一个使用MVC3的网页，该网页应该是高度可定制的。例如，参加电视节目的IMDB页面。它有多个组件（以下称为小部件）：标题信息，演员列表，剧集列表，随机琐事，引用列表，论坛预览等。
假设我正在创建一个IMDB克隆，并根据页面类型（电影，电视节目，演员），显示不同的小部件。用户还可以更改首选项以添加或删除每种类型页面中的某些小部件。
在我的设计中，我拥有它，以便主视图的控制器传递一组“小部件视图模型”，其中包含获取每个小部件所需信息所需的信息。因此它将提供ID（从数据库获取信息），控制器和操作。
在主视图中，它遍历此窗口小部件视图模型列表，并调用html.partial以获取包含每个窗口小部件的公共HTML和JavaScript / jQuery的通用窗口小部件容器局部视图，并将单个窗口小部件视图模型传递给部分观点。
在该局部视图中，在通用窗口小部件容器的内容div中，它调用另一个html.action以通过调用特定控制器操作来获取特定窗口小部件视图，该操作通过id字段获取信息小部件视图模型。
Cliff notes：元数据对象列表 - ＆gt;主要观点。每个元数据对象 - ＆gt;常见的局部视图。部分视图 - ＆gt;另一个使用元数据获取数据的局部视图。
所以现在你已经阅读了所有这些，我有两个问题：
在主视图中有多个html.partial调用相关的成本是多少，每个局部视图调用一个html.action？
这是一个很好的逻辑设计吗？
答案 0 :(得分：3)
有趣的问题 - 我做了几个实验，因为我想知道自己的答案。
1）成本是控制器对象的创建。每次调用Html.Action（）时，都会创建一个控制器对象的新实例。即使您在同一视图的过程中在同一个控制器上调用多个操作也是如此（我试过这个）。这是一种很好的行为，因为它可以确保每个动作都有一个清晰的平台。
@ Html.Partial应该不是负担 - 编译器应该优化。
缺点是如果您的控制器使用外部服务（如数据库）进行繁重的操作，您可能会在提供单个请求时一次打开多个连接（至少一个用于您的父页面和一个请求）对于视图，因为在视图渲染之前控制器不会被处理掉 - 对于子视图，这应该在Html.Action的末尾。所以你需要意识到这一点 - 如果你的行为创造了昂贵的资源，这可能会增加。
2）作为一种设计，尽管如此，它对我来说似乎并不坏。您可以很好地分离关注点，您的个别代码都不会过于复杂，并且您通常总是知道代码的位置。
您必须做出的决策是性能优化与开发优化，这取决于控制器操作的权重。