Asp.Net MVC: Server Controls vs Html class to render controls?

Question

What are the advantages of rendering a control like this:

<% Html.RenderPartial("MyControl") %> or
<%=Html.TextBox("txtName", Model.Name) %>

over the web Forms style:

<uc1:MyControl ID=MyControl runat=server />

I understand that performance can be one reason because no object needs to be created but having the possibility of calling it from the codebehing just to do some basic rendering logic can be very useful.

If this is discouraged then how you are suposed to deal with this scenarios:

• You need to make the control visible conditionally and you dont want to fill your HTML with rendering logic.

• You have <input type="text" value="<%= Model.Name %>" /> but you need to check if Model is null because otherways a NullPointerException will raise.

[EDIT] I asked this when I was beginning with ASP MVC, now I see the advantages of the MVC way like in Cristian answer.

Answer 1

There are a couple of reasons for this. A "traditional" ASP.NET WebForm control encapsulates both the Controller and View aspect of an MVC application and that would be a violation to the pattern. Also by making them extension methods you gain nice abilities such as being able to swap them out with your own implementation and to swap them out for testing

Phil Haack (Program Manager of ASP.NET MVC) talks a bit about this when he got interviewed on the Herdering Code podcast

Episode 24: Phil Haack on the ASP.NET MVC Beta Release (part 1)

http://herdingcode.com/?p=75

Episode 24: Phil Haack on the ASP.NET MVC Beta Release (part 2)

http://herdingcode.com/?p=82

Answer 2

I found this question where @Matt answers:

Does this code A) Process, store, retrieve, perform operations on or analyze the data, or B) Help to display the data?

If the answer is A, it belongs in your controller. If the answer is B, then it belongs in the view.

If B, it ultimately becomes a question of style. If you have some rather long conditional operations for trying to figure out if you display something to the user, then you might hide those conditional operations in the code behind in a Property.

and I agree. To me it is cleaner to write in the aspx:

<custom:HtmlTextBox ID="txtName" runat="server" />

and in the codebehind something like:

if(this.Model != null) 
{
   this.txtName.Text = Model.Name;
}

than in the .aspx for instance:

<% if(this.Model != null) { %>
  <input type="text" name="txtName" value="<%= Model.Name %>" />
<% } else { %>
  <input type="text" name="txtName" value="" />
<% } %>

Being able to manipulate controls from the codebehind is very useful and doesn't violate the MVC pattern. Maybe I am missing something?

Thanks!

Answer 3

Well for your second question, why not do:

<%= Html.TextBox("txtName", ((Model != null) ? Model.Name : "")) %>

In any case, you should be checking in your controller to make sure that your Model isn't null!

Answer 4

Doing null checks in the view is probably going to cause grief in the long run. The way I interpret the MVC style of programming is to prepare the view data in the controller so that the view can be really clean and not sprincled with checks and conditions.

On the other hand, if there is the need follow potentially null associations it's perfectly fine to put that code in a reusable helper, e.g.:

<%= Html.BindTextBox("txtName", Model, "Person.Name") %>

Answer 5

Some purists may say that having code in your view is a violation of the MVC paradigm. RenderPartial creates a fake Page object for your user control - make sure the latter does not depend on the Page object for anything.