January 17, 2021
Hot Topics:

Accepting Input and Manipulating Data in ASP.NET MVC

  • By Jani Järvinen
  • Send Email »
  • More Articles »

ASP.NET MVC is an interesting new technology that supports separating the user interface from the application logic, and the data storage from the data manipulation. When you create ASP.NET MVC applications, the old ASP.NET style of accepting input from the user is no longer the best option. Furthermore, you will also need to learn how to dynamically accept input from the user.

Assume you want to implement a method to process an URL, such as "/products/edit/NNN", where NNN would be an ID number of a product. As you learned in my earlier article, "ASP.NET MVC 101," you would start by writing a public method named Edit in the ProductsController class of your application.

However, how would you be able to retrieve the product ID that the user wants to edit? In regular ASP.NET, you would access the Request object and find the information you want. But in ASP.NET MVC, you have an surprisingly easy alternative. All you need to do is declare the Edit method so that it accepts a parameter with the name "Id", and you are done!

You might wonder how this works. To find the answer, you need to recall the declaration of the default route you saw earlier. Remember how it contained the ID parameter as the third parameter? If you declare a controller method with this parameter, you will automatically get the value as a parameter to your controller when the user accesses the URL.

The routing system in MVC applications looks for particular controller methods that have parameters that match the route parameters. The default route is "{controller}/{action}/{id}", and given the request URL of "/products/edit/123", the system looks for an Edit method that takes parameter with the name "ID" (case is not important). That is, the naming of parameters is important, but so is also typing.

If you want, you can use strongly typed parameters, like an int for parameters that should have an integer value. However, if the request URL is "/products/edit/ABC", "ABC" cannot be converted to an int, and an error results. The string type is the safest bet because all URLs can be represented as strings.

Note that the request could also be simply "/products/edit", in which case there would be no value for the ID parameter. If you had declared your Edit action method with a parameter "int id", an error would result at runtime because ASP.NET MVC would not know which parameter value to pass. To work around the issue, you could use a Nullable int type, and declare your method like this:

public ActionResult Edit(int? id)

With this declaration, the call would still succeed even if the user called the Edit method without an ID parameter. In the controller code, you then could use the ID parameter's HasValue property to check whether there is indeed a value. If you choose to use a string type for the parameter instead, you would simply check whether the parameter is null just like with every other reference type.

Note that, in theory, you also could overload controller methods to accept different parameters, or not accept parameters at all. However, at least in ASP.NET MVC Beta 1, if you try to do this, you will run into errors like this at runtime:

The current request for action 'Edit' on controller type
   'ProductsController' is ambiguous between the following
   action methods...

Given this, it is usually best to use Nullable types in controller methods, or alternatively use reference types.

Allowing the User to Modify Data

In the previous section, you learned how to access parameters from the URL and how ASP.NET MVC parses these into controller parameter values. If you wanted to implement a product edit function in your application, you would need to continue implementing the Edit method in the ProductsController class that you declared previously.

Assume that you would declare the Edit method like this:

public ActionResult Edit(int? id)

Now, if the user would use an URL having an ID parameter of 123, you then could write code in the controller to retrieve the product data from your database given the product ID. ASP.NET MVC doesn't require you to use any particular database access method, so you could use ADO.NET, LINQ, or even your custom methods.

Now, assume your implementation has retrieved a Product class full of data. You already know how to display this data using the view page's model, but how would you easily create editable fields in the HTML code? In regular ASP.NET applications, you would use server-based controls such as the TextBox, CheckBox, or even a DetailsView. Although you can use these controls in ASP.NET MVC applications, you also can use regular HTML form controls directly; in other words, the traditional INPUT fields.

Assuming you are already familiar with the workings of ASP.NET's server-side controls, you might want to learn how the more traditional HTML controls work in ASP.NET MVC applications. Manually creating HTML code for these controls would not be very productive, so it is best to let the framework do the work.

To get what you want, you can use the previously discussed HtmlHelper class in the view page, and use its control creation methods like TextBox, CheckBox, and ListBox. For example, to enable editing of the product's properties, you could write code in your .aspx file like this:

<% using (Html.BeginForm("update", "products")) { %>
      <td>ID: </td>
      <td><%= Html.TextBox("Id", ViewData.Model.Id) %></td>
      <td>Name: </td>
      <td><%= Html.TextBox("Name", ViewData.Model.Name) %></td>
<% } %>

Just as with server-side ASP.NET controls, you need to have an HTML "form" tag somewhere in your .aspx file. This tag should at a minimum contain a "method" attribute (usually POST) and an "action" that specifies the destination of the form post. The HtmlHelper's method BeginForm does just this. Recall that a "runat=server" attribute is not required for HTML-based form controls.

Note that ASP.NET MVC allows you to process forms using the same actions that you use to edit data, but it is often wiser to have a separate action to process the form. For instance, given an URL like "/products/edit/123", you might want to create an action for "/products/update/123" to handle the form processing.

Page 1 of 2

This article was originally published on December 10, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date