Practical ASP.NET
ASP.NET Processing in ASP.NET MVC
Peter Vogel wraps up his series on ASP.NET MVC, for now, by mapping some typical ASP.NET tasks to ASP.NET MVC.
In this series on "ASP.NET MVC for the ASP.NET Developer," I've been looking at ASP.NET MVC on its own terms. However, ASP.NET developers have to be asking how to perform typical tasks in this new environment: how to access data that the user enters into the page, how to respond to the user's actions in the browser, and so on. Some of these overlapping tasks require no explanation: ASP.NET MVC pages can use Master Pages, for instance, and the Session and Cache objects are as available from your server-side code in ASP.NET MVC as they are in ASP.NET.
In ASP.NET MVC, as in ASP.NET MVC, your HTML still includes a form element with at least one submit button. When generating HTML in ASP.NET MVC, however, you don't drag a control onto the page. Instead, you type in an "HTML Helper" that will generate your HTML at runtime. This code, for instance, generates an input tag of type text with its id a<p>nd name attribute set to "fname":</p>mm
<%= Html.TextBox("fname")%>
When you lay out the form element you'll specify a URL to ensure the right Controller and View is called when the user clicks the submit button. Using the HTML helpers you can ensure that the URL used when the submit button is clicked follows the format that your router will use to call the right controller. The major difference here is that control over the HTML generated is managed through the parameters passed to the method rather than through properties on a control.
Some things are completely different in ASP.NET MVC. For instance, you don't use IsPostBack to determine if a page is being displayed to the user for the first time. Instead, you specify which method in a controller is called when a page is first requested by adding an attribute to the method. This method, for instance, will be called when a page is first requested because it has the HttpGet attribute applied to it:
<HttpGet()> _
Function Create() As ActionResult
Return View("NewPage")
End Function
Access to the data on the page is handled differently. The method called when the controller is invoked on a page's postback can be configured to be passed an object with properties for each of the controls on the page. This example, called when a page postbacks, as specified by the HttpPost attribute, accepts a MyUser object that will hold the data from the page:
<HttpPost()> _
Function Create(ByVal user As MyUser) As ActionResult
If user.UserName = "Vogel" Then
What you won't get in ASP.NET MVC is the event model you get with ASP.NET. If you want to determine if the user changed the value in a dropdownlist, you can't put code in the SelectedIndexChanged event. Before moving to ASP.NET MVC from ASP.NET, take a look at your existing applications and determine how often you use client-side events to determine what the user did in the browser.
You also won't get the dynamically generated HTML that ASP.NET controls provide. If you like what the GridView does for you, for instance, and don't want to responsible for doing that yourself then you'll probably be happier with ASP.NET than ASP.NET MVC.
That raises some interesting questions which I'll discuss in my next column.
Read the other columns in this series on ASP.NET MVC development:
ASP.NET MVC for the ASP.NET Programmer
Controlling Controllers in ASP.NET MVC
Viewing Views in ASP.NET MVC
Managing Models in ASP.NET MVC
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.