Is it bad practice for views to create partial(child) views?

I'm creating a little view framework. I'm not trying to stick to开发者_高级运维 strict MVC adherence, but I am definitely trying to not get in the way of MVC practices.

Anyway, one of my questions is this: Is it bad for a view to create it's own child views?

For instance, in pseudo-ish C# code:

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

Is this bad practice for an MVC style? Would the proper thing to do be to provide a "placeholder" in BlogEntryView where the model populates it with CommentViews?

(also, please do not tag asp.net-mvc, this is similar, but in no way uses ASP.Net MVC technologies)

For comparison, the opposite of this, would be adding views with some placeholder in the model code:

/*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));
}

Both ASP.NET MVC and Ruby on Rails facilitate the approach I think your referring to through the use of partial views.

Using your example would typically result in a view that called a partial for comment record. In ASP.NET MVC C# this would look like the following: -

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

Following current MVC philosophies and design principals this sort of decomposition into small "atomic" portions of view code is actively encouraged in many circles. However, there is always a balance to be sought between this decomposition and the maintainability.

No. This is actually how the ASP.NET MVC Templates features work in MVC. However, a potential pitfall in ASP.NET MVC is a slight performance cost to searching the file structure for the views. This can be avoided by specifying the full view path explicitly.

http://vishalswami.blogspot.com/2007/11/design-patterns-in-mvc_30.html discusses MVC architecture. The Gang of Four also advises that one of MVC's greatest advantages is that it facilitates a Composite UI (which is what you are describing).

In traditional MVC, there's one view to each controller and model, which is call the "MVC Triad". I think what you what is the view's template to be able to embed other templates for re-usability (think partials).

One piece of tech that gets this correct with mustache. It uses a view model, coupled with a template. The template can request other partials to reuse chunks of other templates.

The problem with many web MVC frameworks is that they treat the view as a template, which is the wrong way to view it (no pun intended). Once you have a class representing the view, this all becomes much easier.

Personally, I think the specific example you posted is bad form, because a template should never have that sort of access to objects and instantiating them like that. Templates should get their data from outside sources (the view model), which cane make those instantiations cleaner.

Is it bad for a view to create it's own child views? My answer is "NO". In face creating partial views gives you more power to change the UI contents in a modular way.

There are always multiple ways of achieving results. I personally think ascx files are a good clean way of creating reusable modules which can inherit from customized user controls. Its modularized approach keeps things very organized for me.

Just my 2 cents...

I understand that there are communities both pro and against views rendering child views.

Personally I consider the use of RenderPartial to still be a view concern. I don't have an issue with view depending on another view, providing it assumes the same model offered by the controller action's model.

RenderAction on the other hand is less of a view concern because it winds up invoking a controller action, which then renders a view. It's an entire request lifecycle unto itself. However, it has a lot of benefits, particularly for cross-cutting concerns such as site navigation, user account state, ads, or other page features that are completely independent of the page's primary goal.