Question

我正在创建一个小视图框架。我并不是要坚持严格的MVC遵守，但我绝对试图不妨碍MVC实践。

无论如何，我的一个问题是：视图创建自己的子视图是不是很糟糕？

例如，在伪ish C＃代码中：

/*BlogEntryView*/
<h1>my blog entry...</h1>
<div class="Comments">
{# //code
  foreach(var comment in Comments){
    Write(new CommentView(comment));
  }
#}
</div>

这是MVC风格的不良做法吗？正确的做法是在BlogEntryView中提供一个“占位符”，模型用CommentViews填充它吗？

（另外，请不要标记asp.net-mvc，这是类似的，但绝不使用ASP.Net MVC技术）

为了进行比较，与此相反，将在模型代码中添加一些占位符的视图：

/*BlogEntryView*/
<h1>my blog entry...</h1>
<div class="Comments">
{# SomePlaceholder #}
</div>

/*In the model code for BlogEntry*/
//v is a BlogEntryView
foreach(var comment in Comments){
  v.PlaceHolder.Add(new CommentView(comment));
}

Answer 1

ASP.NET MVC和Ruby on Rails都通过使用部分视图来促进我认为你所指的方法。

使用您的示例通常会导致视图调用部分注释记录。在ASP.NET MVC C＃中，这将如下所示： -

<h1>my blog entry...</h1>
<div class="Comments">
  <% foreach (var comment in Model.Comments) { %>
    <% Html.RenderPartial("Comment", comment); %>
  <% } %>
</div>

遵循当前的MVC哲学和设计原则，在许多圈子中积极鼓励这种分解为视图代码的小“原子”部分。但是，在这种分解和可维护性之间总是要寻求平衡。

Answer 2

没有。这实际上是ASP.NET MVC模板功能在MVC中的工作方式。但是，ASP.NET MVC中的潜在缺陷是搜索视图的文件结构会略微降低性能。通过显式指定完整视图路径可以避免这种情况。

http://vishalswami.blogspot.com/2007/11/design-patterns-in-mvc_30.html讨论了MVC架构。 Gang of Four还建议MVC最大的优势之一是它促进了复合UI（这就是你所描述的）。

Answer 3

在传统的MVC中，每个控制器和模型都有一个视图，称为“MVC三元组”。我认为你的视图模板是什么，能够嵌入其他模板以实现可重用性（想想部分）。

使用mustache获得此功能的一项技术。它使用视图模型，再加上模板。模板可以请求其他部分重用其他模板的块。

许多Web MVC框架的问题在于它们将视图视为模板，这是查看它的错误方式（没有双关语意）。一旦你有一个代表视图的类，这一切就变得容易了。

就个人而言，我认为您发布的具体示例是错误的形式，因为模板永远不应该具有对对象的那种访问权限并且像这样实例化它们。模板应该从外部源（视图模型）获取数据，这些实例可以使这些实例更清晰。

Answer 4

视图创建自己的子视图是不是很糟糕？我的回答是“不”。在创建局部视图时，您可以以模块化方式更改UI内容。

总有多种方法可以达到效果。我个人认为ascx文件是创建可重用模块的一种很好的清洁方式，可以从定制的用户控件继承。它的模块化方法让我的事情变得非常有条理。

只是我的2美分......

Answer 5

我知道有些社区既赞成也反对视图呈现子视图。

我个人认为RenderPartial的使用仍然是一个视角问题。我根据另一个视图没有视图问题，假设它采用控制器动作模型提供的相同模型。

另一方面，

RenderAction不是一个关注点，因为它最终调用一个控制器动作，然后呈现一个视图。这是一个完整的请求生命周期。但是，它具有很多好处，特别是对于横切关注点，例如站点导航，用户帐户状态，广告或完全独立于页面主要目标的其他页面功能。

视图创建部分（子）视图是不好的做法？

5 个答案: