What’s The First Thing To Learn About ASP.NET MVC?

Monday, November 30, 2009

If you are an ASP.NET Web Forms programmer making the switch to ASP.NET MVC – what’s the first thing you should learn?

There are lots of candidates for the number one spot. Some people will say the first thing to do is learn and embrace the spirit of the MVC design pattern. Others might say you should learn how to unit test a controller, or learn how to use a view model.

fill out your forms! My answer is:

Learn how to use an HTML <form>.

Please excuse the ASP.NET web forms programmer who forgets about the <form> tag. Although every .aspx file has one, they never need to touch it, or even look at it. The form tag is not only well hidden, but also constrained. It only take a few years to start thinking the web revolves around pages that only submit information back to themselves.

The most important things to lean (or relearn) are:

  • You can use the method attribute of <form> to specify the HTTP method to use for  submission (GET or POST).
  • You can use the action attribute of the <form> to submit information to any URL.
  • You can have multiple <form> tags on a single page.

Let’s look at each case.

Method Attribute – GET versus POST

There are two types of requests a web browser will use when communicating with a web server – POST requests and GET requests. Both are designed to do what they sound like – GET a response, or POST some information and receive a response. Web forms always use POST methods. HTTP POST is the best method to use when you are submitting information to a web server and changing state in your application. For example, if a user fills out a <form> with textbox and radio button controls full of patient information you want to save in a database, then POST is the HTTP method you should use. The browser will POST the user’s values to the server where you can save them in the database, and then you can respond and tell the user everything worked (or tell them something blew up).

On the other hand, an HTTP GET operation operation is the best way to submit information to a server when you are not changing state inside the application. The best example is a form used to search for information. You need to send search parameters to the server, but the search parameters aren’t creating new records in a database – they are only used as to query information.

image <form action="/search" method="get">
    <input type="text" name="searchTerm" />
    <input type="submit" value="Search" />
</form>

If the user enters “baby blue bathysphere” into the textbox and clicks the button, the browser will send off a GET request with the following URL:

 /search?searchTerm=baby+blue+bathysphere

Notice how the submitted form values are placed in the URL itself. Not only is a GET operation cacheable, but users can also bookmark the response to a GET submission because all the information needed to produce the page is in the URL. GET is the default value for the method attribute of a <form>, so if you don’t specify the method you’ll have a GET by default.

Actions

ASP.NET web forms always POST to themselves, which can be limiting. As the previous example demonstrates, you can set the action attribute to submit a form to any URL, even a URL pointing to another application on a different server. For example, the following HTML would send the user to Google (both Google and Bing both expect the search parameter to have the name “q”).

<form action="http://google.com/search" method="get">
    <input type="text" name="q" />
    <input type="submit" value="Search" />
</form>

You’ll usually be setting the action attribute to submit information to some controller action in your MVC application. The Html.BeginForm helpers will help build the correct <form> tag to reach the desired action for you. If we were using the first code-snippet in this post (the one with an action of “/search”), we could respond to the search request with the default action of a SearchController. The MVC framework can automatically pass the searchTerm form parameter as a parameter to the action.

public class SearchController : Controller
{
    public ActionResult Index(string searchTerm)
    {
        // ....
        return View();
    }
}

Two Forms Are Better Than One

Well … not always.

There are times when having multiple <form> tags on a page is a good idea. You can have two distinct pieces of a page submit information to two different URLs. Multiple <form> tags regularly make sense on portal type pages that contain multiple sections with disparate functionality. Like an area that lets a user get a stock quote, and an area that lets a user search for a movie. These are two different tasks that will probably best be handled by two different controllers, two different URLs, two different forms, and two different sets of input controls.

<form action="/stock/quote">
    <input type="text" name="symbol" />
    <input type="submit" value="Quote It!" />
</form>

<!-- ... --->

<form action="/movie/search">
    <input type="text" name="q" />
    <input type="submit" value="Search" />
</form>

Not every scenario requires multiple forms, however. Sometimes you want a single form to provoke different behaviors from the server. For example, imagine a shopping page where a user selects some check boxes for products they are interested in. You might need a button allowing the user to submit this information to “compare products” and another button allowing the user to save the selected items in a “wish list”. Both buttons need to submit the same information to the server, so they’ll probably live inside the same form

<form action="products/shop" method="post">
    <!-- -->
    <input type="submit" name="task" value="Compare" />
    <input type="submit" name="task" value="Save to wish list" />
</form>

Both buttons in the above form will force the browser to POST to products/shop. Notice how both buttons have the same value for the name attribute, but their values are different. In an MVC application you can create a controller to accept this form submission:

public class ProductsController : Controller
{
    [AcceptVerbs(HttpVerbs.Post)]        
    public ActionResult Shop(string task)
    {
        // ...
        return View();
    }
}

The value of the task parameter in the Shop action will contain the value of the button – either “Compare” or “Save to wish list”. You can inspect this value and decide what to do next.

Conclusion

Having <form> tags available to due your bidding in an MVC application allows you a great deal of flexibility and control. Every bit you learn about using forms will give you an edge in building your application. Experiment with them, read about them, and learn to love them!


Comments
gravatar Steve Monday, November 30, 2009
reminds/looks like classic ASP to me :)
gravatar Shiju Vaarghese Monday, November 30, 2009
The sad things is that many web form developers do not know the basics of HTTP and HTML. This is a nice post that would be help many web form developers.
gravatar scott Monday, November 30, 2009
@Steve - it's back! :)

@Shiju - thanks!
gravatar Kalpesh Tuesday, December 1, 2009
Yes,

Reminds me of good old classic ASP, where one had to write vbscript mixed with html.

<input type="submit"....
<%= %>

Too much of wrapped functionality & one loses the control over basic things. It has happened with webforms.

Good post as always.
gravatar Donn Tuesday, December 1, 2009
Well said K. Scott. I def agree here. Let's bring it back to the basics. Once dev's understand that, MVC is cake walk IMO.
Andy Rose Tuesday, December 1, 2009
Great summary of the form tag. It is very true that the ASP.NET abstraction hides this detail from developers which makes the transition to MVC a little harder.
In fairness to web forms it would be worth mentioning that as of ASP.NET 2.0 it is possible to post form data to different URLs using the Cross Page Posting property.
gravatar Matt Briggs Tuesday, December 1, 2009
Great post, I was explaining MVC to another developer here awhile back. I was pretty surprised when I found how big a hurdle multiple forms were to grok for him. I guess it is cause I have only been doing the webforms thing for about two years now, and he has been at it pretty much since asp.net came out.
gravatar Garry Pilkington Wednesday, December 2, 2009
I started out developing web sites using classic asp, and have gone through the ASP.Net webforms and now use MVC and I am amazed at how easy it is and reminds me of the old days. It certainly helps to get an understanding of the whole http cycle and forms in particular, nice post.
gravatar john Wednesday, December 2, 2009
it's not the old days or a step backward. It's called Web Development. It's how the rest of the non-web forms world does it. i think it's funny that someone feels the need to explain what form action and form method is to a group of web devs?? wtf. If i were hiring for a web forms position and all the dev knew was web forms i would not hire the person. that tells me the person is only it for a paycheck and not genuinely interested in the world of webdev.
gravatar Scott Allen Thursday, December 3, 2009
@john - I agree to a point. If you don't use something because it is hidden away from you, I think you'll tend to forget. Like in my case, I don't remember x86 assembly language instructions like I used to :)
gravatar Alireza Ramezani Thursday, December 3, 2009
I agree with Matt too ,Great post, I was explaining MVC to another developer here awhile back. I was pretty surprised when I found how big a hurdle multiple forms were to grok for him. I guess it is cause I have only been doing the webforms thing for about two years now, and he has been at it pretty much since asp.net came out
gravatar Court Newman Thursday, December 3, 2009
I just came back from a Microsoft PDC conference and one of the sessions there was about MVC. The session was more of a group discussion and the number one complaint that I heard of MVC is that you lose the asp.net controls. Of which I think brings us back to: if you know basic HTML, then you don't have to worry about the loss of asp.net controls.
gravatar Santosh Jha Friday, December 4, 2009
Nice basic tip keep it up!!!
gravatar qureshi Saturday, December 5, 2009
very useful basic information

thanx
gravatar Marwan Elshemi Saturday, December 5, 2009
wondefull
I'm going back to learn Html <Form></Form>
the best thing to learn the basis of thing
thaaaaaanx
gravatar JonW Saturday, December 5, 2009
Correction, you DON'T have to have to use Form Runat server with asp.net.
Only if you use webcontrols in your aspx directly who in turn needs a form (like textbox, datagrid etc)
You can use Repeater WITHOUT a form, you can even use multiple html STANDARD form, with get/post with .aspx. If one use regular html lika input type text you don't need Form runat server (what about databinding?) use similar/same technique to bind from post variables like MVC does...

you could also render a gridview in memory and put the generated HTML to a say lika a literalcontrol.

I concur that WebForms developers should REALLY learn standard (x)html before touching webcontrols.
gravatar Pieter Saturday, December 5, 2009
The dirty old days are coming back...
gravatar Mikesdotnetting Saturday, December 5, 2009
Peter said: "The dirty old days are coming back..."

Dirty is as dirty does. I've seen some very dirty web forms apps in my time.

Chris Saturday, December 5, 2009
Adressing the perception that MVC looks like a step backwards due to the inline code, etc... Keep in mind that was messy primarily because it was presentation code and application logic all mixed up with each other.

Web Forms attempted to solve this by isolating presentation in the .aspx page and putting application logic in the code-behind.

This works, even tho sometimes you have to do odd things in the code-behind to output appropriate things in the HTML from time to time.

It's definitely better than classic ASP, but the real problem is that application logic doesn't belong in the presentation layer at all!

You can use web forms "correctly" to solve this problem by creating business objects and static methods, etc... but MVC, by design, actually *forces* us to move the application logic into the controller where it belongs. So, it is hard to be lazy and do things the wrong way.

Which is good because it leaves us with a much more basic set of data to deal with in the view, data that is much more tuned to being handled with these techniques that feel more like classic ASP.

Both approaches are valid - I don't think there is any intention to convert all web forms folks or projects to MVC but it is probably a better approach for certain types of problems.

I'd suggest anybody who hasn't tried it to grab a sample and work through it a bit and you'll see how refreshing it can be.
gravatar Darren Sunday, December 6, 2009
Not bad review of MVC but I wonder I am doing quite well currently using web client software factory (MVP framework), do I really need to switch? Which framework would be better for rapid developement?
gravatar Sangam Uprety Monday, December 7, 2009
Thanks a lot. Very interesting post. Honestly speaking I never digged into such beauty of form element. That abstractism of asp.net web form always made me just use it and forget all the hows! Now since I am longing to learn [I won't like to say 'migrate to'!] asp.net mvc, I will sure enjoy the true story behing html! Thanks again!!
gravatar BJL Monday, December 7, 2009
Hmmm. I'm still not sure what all the hype is about, so I'm asking you guys to enlighten me... As far as I have it, the MVC design pattern is nothing new, in fact, its been around for a while. Why all the hype all of a sudden?

What exactly is the function of the MVC Framework and what is so "revolutionary" about it?
gravatar scott Monday, December 7, 2009
@BJL - There is nothing new about the pattern. There is nothing new about the framework, either. In fact, Microsoft's framework is a lot like the other MVC frameworks.
gravatar DC Tuesday, December 8, 2009
MVC got its start in '79(wikipedia). Microsoft is a marketing machine and markets technology to programmers. Programmers buy in to the latest greatest advertisements thinking it is a must learn situation for their next job and thereby creates a self fulfilling prophecy that keeps the ad campaign running strong by promoting the next latest and greatest to management who then institutionalizes the change. POST/GET was alive and well for years with vbscript and yes it wasn't clean code so to speak, but PHP is just now coming into the OOP realm and huge sites have been built with these technologies. Web forms still has POST/GET. We jump at the next release of technology from others as well as microsoft. why? Sometimes it can make a difference and sometimes not. More tools for one's toolbox. Until the next software pattern then ... MVVM anyone anyone ;)
gravatar Kapil Thursday, December 10, 2009
Ultimate ....
Really i never thought of this...Great Post ..Thank you Scott
vgv8 Monday, December 14, 2009
"GET is the default value for the method attribute of a <form>, so if you don’t specify the method you’ll have a GET by default.
Actions
ASP.NET web forms always POST to themselves"

I am confused:
when the POST is default
and
when the GET is?
gravatar scott Monday, December 14, 2009
@vgv8 - Sorry for the confusion.

For an HTML form tag the default is a GET.

In ASP.NET Web Forms the server side form (the form tag with runat="server") that ASP.NET writes out always uses method="post", so when you are using web forms ASP.NET overrides the default to always POST to themselves.
gravatar Neil Tuesday, January 12, 2010
Asp is coming home! After years of having to put up with MS trying to save client server developers careers by getting them to do "web" stuff we now get a proper, fast, lightweight framework and are binning that slow, viewstate ridden pile of webform crud. A breathe of fresh air. I am so happy.
teddy Friday, February 26, 2010
MVP is just MS way of lessening Rails rising popularity
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!