Provide CRUD (Create, Read, Update, Delete) Data Form Entry Support
by Microsoft
This is step 5 of a free “NerdDinner” application tutorial that walks-through how to build a small, but complete, web application using ASP.NET MVC 1.
Step 5 shows how to take our DinnersController class further by enable support for editing, creating and deleting Dinners with it as well.
If you are using ASP.NET MVC 3, we recommend you follow the Getting Started With MVC 3 or MVC Music Store tutorials.
NerdDinner Step 5: Create, Update, Delete Form Scenarios
We’ve introduced controllers and views, and covered how to use them to implement a listing/details experience for Dinners on site. Our next step will be to take our DinnersController class further and enable support for editing, creating and deleting Dinners with it as well.
URLs handled by DinnersController
We previously added action methods to DinnersController that implemented support for two URLs: /Dinners and /Dinners/Details/[id].
| URL | VERB | Purpose |
|---|---|---|
| /Dinners/ | GET | Display an HTML list of upcoming dinners. |
| /Dinners/Details/[id] | GET | Display details about a specific dinner. |
We will now add action methods to implement three additional URLs: /Dinners/Edit/[id], /Dinners/Create,and/Dinners/Delete/[id]. These URLs will enable support for editing existing Dinners, creating new Dinners, and deleting Dinners.
We will support both HTTP GET and HTTP POST verb interactions with these new URLs. HTTP GET requests to these URLs will display the initial HTML view of the data (a form populated with the Dinner data in the case of “edit”, a blank form in the case of “create”, and a delete confirmation screen in the case of “delete”). HTTP POST requests to these URLs will save/update/delete the Dinner data in our DinnerRepository (and from there to the database).
| URL | VERB | Purpose |
|---|---|---|
| /Dinners/Edit/[id] | GET | Display an editable HTML form populated with Dinner data. |
| POST | Save the form changes for a particular Dinner to the database. | |
| /Dinners/Create | GET | Display an empty HTML form that allows users to define new Dinners. |
| POST | Create a new Dinner and save it in the database. | |
| /Dinners/Delete/[id] | GET | Display delete confirmation screen. |
| POST | Deletes the specified dinner from the database. |
Edit Support
Let’s begin by implementing the “edit” scenario.
The HTTP-GET Edit Action Method
We’ll start by implementing the HTTP “GET” behavior of our edit action method. This method will be invoked when the /Dinners/Edit/[id] URL is requested. Our implementation will look like:
[!code-csharpMain]
1: //
2: // GET: /Dinners/Edit/2
3:
4: public ActionResult Edit(int id) {
5:
6: Dinner dinner = dinnerRepository.GetDinner(id);
7:
8: return View(dinner);
9: }
The code above uses the DinnerRepository to retrieve a Dinner object. It then renders a View template using the Dinner object. Because we haven’t explicitly passed a template name to the View() helper method, it will use the convention based default path to resolve the view template: /Views/Dinners/Edit.aspx.
Let’s now create this view template. We will do this by right-clicking within the Edit method and selecting the “Add View” context menu command:
Within the “Add View” dialog we’ll indicate that we are passing a Dinner object to our view template as its model, and choose to auto-scaffold an “Edit” template:
When we click the “Add” button, Visual Studio will add a new “Edit.aspx” view template file for us within the “” directory. It will also open up the new “Edit.aspx” view template within the code-editor – populated with an initial “Edit” scaffold implementation like below:
Let’s make a few changes to the default “edit” scaffold generated, and update the edit view template to have the content below (which removes a few of the properties we don’t want to expose):
[!code-aspxMain]
1: <asp:Content ID="Title" ContentPlaceHolderID="TitleContent" runat="server">
2: Edit: <%=Html.Encode(Model.Title)%>
3: </asp:Content>
4:
5: <asp:Content ID="Main" ContentPlaceHolderID="MainContent" runat="server">
6:
7: <h2>Edit Dinner</h2>
8:
9: <%=Html.ValidationSummary("Please correct the errors and try again.") %>
10:
11: <% using (Html.BeginForm()) { %>
12:
13: <fieldset>
14: <p>
15: <label for="Title">Dinner Title:</label>
16: <%=Html.TextBox("Title") %>
17: <%=Html.ValidationMessage("Title", "*") %>
18: </p>
19: <p>
20: <label for="EventDate">EventDate:</label>
21: <%=Html.TextBox("EventDate", String.Format("{0:g}", Model.EventDate))%>
22: <%=Html.ValidationMessage("EventDate", "*") %>
23: </p>
24: <p>
25: <label for="Description">Description:</label>
26: <%=Html.TextArea("Description") %>
27: <%=Html.ValidationMessage("Description", "*")%>
28: </p>
29: <p>
30: <label for="Address">Address:</label>
31: <%=Html.TextBox("Address") %>
32: <%=Html.ValidationMessage("Address", "*") %>
33: </p>
34: <p>
35: <label for="Country">Country:</label>
36: <%=Html.TextBox("Country") %>
37: <%=Html.ValidationMessage("Country", "*") %>
38: </p>
39: <p>
40: <label for="ContactPhone">ContactPhone #:</label>
41: <%=Html.TextBox("ContactPhone") %>
42: <%=Html.ValidationMessage("ContactPhone", "*") %>
43: </p>
44: <p>
45: <label for="Latitude">Latitude:</label>
46: <%=Html.TextBox("Latitude") %>
47: <%=Html.ValidationMessage("Latitude", "*") %>
48: </p>
49: <p>
50: <label for="Longitude">Longitude:</label>
51: <%=Html.TextBox("Longitude") %>
52: <%=Html.ValidationMessage("Longitude", "*") %>
53: </p>
54: <p>
55: <input type="submit" value="Save"/>
56: </p>
57: </fieldset>
58:
59: <% } %>
60:
61: </asp:Content>
When we run the application and request the “/Dinners/Edit/1” URL we will see the following page:
The HTML markup generated by our view looks like below. It is standard HTML – with a <form> element that performs an HTTP POST to the /Dinners/Edit/1 URL when the “Save” <input type=“submit”/> button is pushed. A HTML <input type=“text”/> element has been output for each editable property:
Html.BeginForm() and Html.TextBox() Html Helper Methods
Our “Edit.aspx” view template is using several “Html Helper” methods: Html.ValidationSummary(), Html.BeginForm(), Html.TextBox(), and Html.ValidationMessage(). In addition to generating HTML markup for us, these helper methods provide built-in error handling and validation support.
Html.BeginForm() helper method
The Html.BeginForm() helper method is what output the HTML <form> element in our markup. In our Edit.aspx view template you’ll notice that we are applying a C# “using” statement when using this method. The open curly brace indicates the beginning of the <form> content, and the closing curly brace is what indicates the end of the </form> element:
[!code-csharpMain]
1: <% using (Html.BeginForm()) { %>
2:
3: <fieldset>
4:
5: <!-- Fields Omitted for Brevity -->
6:
7: <p>
8: <input type="submit" value="Save"/>
9: </p>
10: </fieldset>
11:
12: <% } %>
Alternatively, if you find the “using” statement approach unnatural for a scenario like this, you can use a Html.BeginForm() and Html.EndForm() combination (which does the same thing):
[!code-aspxMain]
1: <% Html.BeginForm(); %>
2:
3: <fieldset>
4:
5: <!-- Fields Omitted for Brevity -->
6:
7: <p>
8: <input type="submit" value="Save"/>
9: </p>
10: </fieldset>
11:
12: <% Html.EndForm(); %>
Calling Html.BeginForm() without any parameters will cause it to output a form element that does an HTTP-POST to the current request’s URL. That is why our Edit view generates a <form action=“/Dinners/Edit/1” method=“post”> element. We could have alternatively passed explicit parameters to Html.BeginForm() if we wanted to post to a different URL.
Html.TextBox() helper method
Our Edit.aspx view uses the Html.TextBox() helper method to output <input type=“text”/> elements:
[!code-aspxMain]
1: <%= Html.TextBox("Title") %>
The Html.TextBox() method above takes a single parameter – which is being used to specify both the id/name attributes of the <input type=“text”/> element to output, as well as the model property to populate the textbox value from. For example, the Dinner object we passed to the Edit view had a “Title” property value of “.NET Futures”, and so our Html.TextBox(“Title”) method call output: <input id=“Title” name=“Title” type=“text” value=“.NET Futures” />.
Alternatively, we can use the first Html.TextBox() parameter to specify the id/name of the element, and then explicitly pass in the value to use as a second parameter:
[!code-aspxMain]
1: <%= Html.TextBox("Title", Model.Title)%>
Often we’ll want to perform custom formatting on the value that is output. The String.Format() static method built-into .NET is useful for these scenarios. Our Edit.aspx view template is using this to format the EventDate value (which is of type DateTime) so that it doesn’t show seconds for the time:
[!code-aspxMain]
1: <%= Html.TextBox("EventDate", String.Format("{0:g}", Model.EventDate)) %>
A third parameter to Html.TextBox() can optionally be used to output additional HTML attributes. The code-snippet below demonstrates how to render an additional size=“30” attribute and a class=“mycssclass” attribute on the <input type=“text”/> element. Note how we are escaping the name of the class attribute using a “@” character because “class” is a reserved keyword in C#:
[!code-aspxMain]
1: <%= Html.TextBox("Title", Model.Title, new { size=30, @class="myclass" } )%>
Implementing the HTTP-POST Edit Action Method
We now have the HTTP-GET version of our Edit action method implemented. When a user requests the /Dinners/Edit/1 URL they receive an HTML page like the following:
Pressing the “Save” button causes a form post to the /Dinners/Edit/1 URL, and submits the HTML <input> form values using the HTTP POST verb. Let’s now implement the HTTP POST behavior of our edit action method – which will handle saving the Dinner.
We’ll begin by adding an overloaded “Edit” action method to our DinnersController that has an “AcceptVerbs” attribute on it that indicates it handles HTTP POST scenarios:
[!code-csharpMain]
1: //
2: // POST: /Dinners/Edit/2
3:
4: [AcceptVerbs(HttpVerbs.Post)]
5: public ActionResult Edit(int id, FormCollection formValues) {
6: ...
7: }
When the [AcceptVerbs] attribute is applied to overloaded action methods, ASP.NET MVC automatically handles dispatching requests to the appropriate action method depending on the incoming HTTP verb. HTTP POST requests to /Dinners/Edit/[id] URLs will go to the above Edit method, while all other HTTP verb requests to /Dinners/Edit/[id]URLs will go to the first Edit method we implemented (which did not have an [AcceptVerbs] attribute).
| Side Topic: Why differentiate via HTTP verbs? |
|---|
| You might ask – why are we using a single URL and differentiating its behavior via the HTTP verb? Why not just have two separate URLs to handle loading and saving edit changes? For example: /Dinners/Edit/[id] to display the initial form and /Dinners/Save/[id] to handle the form post to save it? The downside with publishing two separate URLs is that in cases where we post to /Dinners/Save/2, and then need to redisplay the HTML form because of an input error, the end-user will end up having the /Dinners/Save/2 URL in their browser’s address bar (since that was the URL the form posted to). If the end-user bookmarks this redisplayed page to their browser favorites list, or copy/pastes the URL and emails it to a friend, they will end up saving a URL that won’t work in the future (since that URL depends on post values). By exposing a single URL (like: /Dinners/Edit/[id]) and differentiating the processing of it by HTTP verb, it is safe for end-users to bookmark the edit page and/or send the URL to others. |
Retrieving Form Post Values
There are a variety of ways we can access posted form parameters within our HTTP POST “Edit” method. One simple approach is to just use the Request property on the Controller base class to access the form collection and retrieve the posted values directly:
[!code-csharpMain]
1: //
2: // POST: /Dinners/Edit/2
3:
4: [AcceptVerbs(HttpVerbs.Post)]
5: public ActionResult Edit(int id, FormCollection formValues) {
6:
7: // Retrieve existing dinner
8: Dinner dinner = dinnerRepository.GetDinner(id);
9:
10: // Update dinner with form posted values
11: dinner.Title = Request.Form["Title"];
12: dinner.Description = Request.Form["Description"];
13: dinner.EventDate = DateTime.Parse(Request.Form["EventDate"]);
14: dinner.Address = Request.Form["Address"];
15: dinner.Country = Request.Form["Country"];
16: dinner.ContactPhone = Request.Form["ContactPhone"];
17:
18: // Persist changes back to database
19: dinnerRepository.Save();
20:
21: // Perform HTTP redirect to details page for the saved Dinner
22: return RedirectToAction("Details", new { id = dinner.DinnerID });
23: }
The above approach is a little verbose, though, especially once we add error handling logic.
A better approach for this scenario is to leverage the built-in UpdateModel() helper method on the Controller base class. It supports updating the properties of an object we pass it using the incoming form parameters. It uses reflection to determine the property names on the object, and then automatically converts and assigns values to them based on the input values submitted by the client.
We could use the UpdateModel() method to simplify our HTTP-POST Edit Action using this code:
[!code-csharpMain]
1: //
2: // POST: /Dinners/Edit/2
3:
4: [AcceptVerbs(HttpVerbs.Post)]
5: public ActionResult Edit(int id, FormCollection formValues) {
6:
7: Dinner dinner = dinnerRepository.GetDinner(id);
8:
9: UpdateModel(dinner);
10:
11: dinnerRepository.Save();
12:
13: return RedirectToAction("Details", new { id = dinner.DinnerID });
14: }
We can now visit the /Dinners/Edit/1 URL, and change the title of our Dinner:
When we click the “Save” button, we’ll perform a form post to our Edit action, and the updated values will be persisted in the database. We will then be redirected to the Details URL for the Dinner (which will display the newly saved values):
Handling Edit Errors
Our current HTTP-POST implementation works fine – except when there are errors.
When a user makes a mistake editing a form, we need to make sure that the form is redisplayed with an informative error message that guides them to fix it. This includes cases where an end-user posts incorrect input (for example: a malformed date string), as well as cases where the input format is valid but there is a business rule violation. When errors occur the form should preserve the input data the user originally entered so that they don’t have to refill their changes manually. This process should repeat as many times as necessary until the form successfully completes.
ASP.NET MVC includes some nice built-in features that make error handling and form redisplay easy. To see these features in action let’s update our Edit action method with the following code:
[!code-csharpMain]
1: //
2: // POST: /Dinners/Edit/2
3:
4: [AcceptVerbs(HttpVerbs.Post)]
5: public ActionResult Edit(int id, FormCollection formValues) {
6:
7: Dinner dinner = dinnerRepository.GetDinner(id);
8:
9: try {
10:
11: UpdateModel(dinner);
12:
13: dinnerRepository.Save();
14:
15: return RedirectToAction("Details", new { id=dinner.DinnerID });
16: }
17: catch {
18:
19: foreach (var issue in dinner.GetRuleViolations()) {
20: ModelState.AddModelError(issue.PropertyName, issue.ErrorMessage);
21: }
22:
23: return View(dinner);
24: }
25: }
The above code is similar to our previous implementation – except that we are now wrapping a try/catch error handling block around our work. If an exception occurs either when calling UpdateModel(), or when we try and save the DinnerRepository (which will raise an exception if the Dinner object we are trying to save is invalid because of a rule violation within our model), our catch error handling block will execute. Within it we loop over any rule violations that exist in the Dinner object and add them to a ModelState object (which we’ll discuss shortly). We then redisplay the view.
To see this working let’s re-run the application, edit a Dinner, and change it to have an empty Title, an EventDate of “BOGUS”, and use a UK phone number with a country value of USA. When we press the “Save” button our HTTP POST Edit method will not be able to save the Dinner (because there are errors) and will redisplay the form:
Our application has a decent error experience. The text elements with the invalid input are highlighted in red, and validation error messages are displayed to the end user about them. The form is also preserving the input data the user originally entered – so that they don’t have to refill anything.
How, you might ask, did this occur? How did the Title, EventDate, and ContactPhone textboxes highlight themselves in red and know to output the originally entered user values? And how did error messages get displayed in the list at the top? The good news is that this didn’t occur by magic - rather it was because we used some of the built-in ASP.NET MVC features that make input validation and error handling scenarios easy.
Understanding ModelState and the Validation HTML Helper Methods
Controller classes have a “ModelState” property collection which provides a way to indicate that errors exist with a model object being passed to a View. Error entries within the ModelState collection identify the name of the model property with the issue (for example: “Title”, “EventDate”, or “ContactPhone”), and allow a human-friendly error message to be specified (for example: “Title is required”).
The UpdateModel() helper method automatically populates the ModelState collection when it encounters errors while trying to assign form values to properties on the model object. For example, our Dinner object’s EventDate property is of type DateTime. When the UpdateModel() method was unable to assign the string value “BOGUS” to it in the scenario above, the UpdateModel() method added an entry to the ModelState collection indicating an assignment error had occurred with that property.
Developers can also write code to explicitly add error entries into the ModelState collection like we are doing below within our “catch” error handling block, which is populating the ModelState collection with entries based on the active Rule Violations in the Dinner object:
[!code-csharpMain]
1: [AcceptVerbs(HttpVerbs.Post)]
2: public ActionResult Edit(int id, FormCollection formValues) {
3:
4: Dinner dinner = dinnerRepository.GetDinner(id);
5:
6: try {
7:
8: UpdateModel(dinner);
9:
10: dinnerRepository.Save();
11:
12: return RedirectToAction("Details", new { id=dinner.DinnerID });
13: }
14: catch {
15:
16: foreach (var issue in dinner.GetRuleViolations()) {
17: ModelState.AddModelError(issue.PropertyName, issue.ErrorMessage);
18: }
19:
20: return View(dinner);
21: }
22: }
Html Helper Integration with ModelState
HTML helper methods - like Html.TextBox() - check the ModelState collection when rendering output. If an error for the item exists, they render the user-entered value and a CSS error class.
For example, in our “Edit” view we are using the Html.TextBox() helper method to render the EventDate of our Dinner object:
[!code-aspxMain]
1: <%= Html.TextBox("EventDate", String.Format("{0:g}", Model.EventDate)) %>
When the view was rendered in the error scenario, the Html.TextBox() method checked the ModelState collection to see if there were any errors associated with the “EventDate” property of our Dinner object. When it determined that there was an error it rendered the submitted user input (“BOGUS”) as the value, and added a css error class to the <input type=“textbox”/> markup it generated:
[!code-htmlMain]
1: <input class="input-validation-error"id="EventDate" name="EventDate" type="text" value="BOGUS"/>
You can customize the appearance of the css error class to look however you want. The default CSS error class – “input-validation-error” – is defined in the .css stylesheet and looks like below:
[!code-cssMain]
1: .input-validation-error
2: {
3: border: 1px solid #ff0000;
4: background-color: #ffeeee;
5: }
This CSS rule is what caused our invalid input elements to be highlighted like below:
Html.ValidationMessage() Helper Method
The Html.ValidationMessage() helper method can be used to output the ModelState error message associated with a particular model property:
[!code-aspxMain]
1: <%= Html.ValidationMessage("EventDate")%>
The above code outputs: <span class=“field-validation-error”> The value ‘BOGUS’ is invalid</span>
The Html.ValidationMessage() helper method also supports a second parameter that allows developers to override the error text message that is displayed:
[!code-aspxMain]
1: <%= Html.ValidationMessage("EventDate","*") %>
The above code outputs: <span class=“field-validation-error”>*</span>instead of the default error text when an error is present for the EventDate property.
Html.ValidationSummary() Helper Method
The Html.ValidationSummary() helper method can be used to render a summary error message, accompanied by a <ul><li/></ul> list of all detailed error messages in the ModelState collection:
The Html.ValidationSummary() helper method takes an optional string parameter – which defines a summary error message to display above the list of detailed errors:
[!code-aspxMain]
1: <%= Html.ValidationSummary("Please correct the errors and try again.") %>
You can optionally use CSS to override what the error list looks like.
Using a AddRuleViolations Helper Method
Our initial HTTP-POST Edit implementation used a foreach statement within its catch block to loop over the Dinner object’s Rule Violations and add them to the controller’s ModelState collection:
[!code-csharpMain]
1: catch {
2: foreach (var issue in dinner.GetRuleViolations()) {
3: ModelState.AddModelError(issue.PropertyName, issue.ErrorMessage);
4: }
5:
6: return View(dinner);
7: }
We can make this code a little cleaner by adding a “ControllerHelpers” class to the NerdDinner project, and implement an “AddRuleViolations” extension method within it that adds a helper method to the ASP.NET MVC ModelStateDictionary class. This extension method can encapsulate the logic necessary to populate the ModelStateDictionary with a list of RuleViolation errors:
[!code-csharpMain]
1: public static class ControllerHelpers {
2:
3: public static void AddRuleViolations(this ModelStateDictionary modelState, IEnumerable<RuleViolation> errors) {
4:
5: foreach (RuleViolation issue in errors) {
6: modelState.AddModelError(issue.PropertyName, issue.ErrorMessage);
7: }
8: }
9: }
We can then update our HTTP-POST Edit action method to use this extension method to populate the ModelState collection with our Dinner Rule Violations.
Complete Edit Action Method Implementations
The code below implements all of the controller logic necessary for our Edit scenario:
[!code-csharpMain]
1: //
2: // GET: /Dinners/Edit/2
3:
4: public ActionResult Edit(int id) {
5:
6: Dinner dinner = dinnerRepository.GetDinner(id);
7:
8: return View(dinner);
9: }
10:
11: //
12: // POST: /Dinners/Edit/2
13:
14: [AcceptVerbs(HttpVerbs.Post)]
15: public ActionResult Edit(int id, FormCollection formValues) {
16:
17: Dinner dinner = dinnerRepository.GetDinner(id);
18:
19: try {
20:
21: UpdateModel(dinner);
22:
23: dinnerRepository.Save();
24:
25: return RedirectToAction("Details", new { id=dinner.DinnerID });
26: }
27: catch {
28:
29: ModelState.AddRuleViolations(dinner.GetRuleViolations());
30:
31: return View(dinner);
32: }
33: }
The nice thing about our Edit implementation is that neither our Controller class nor our View template has to know anything about the specific validation or business rules being enforced by our Dinner model. We can add additional rules to our model in the future and do not have to make any code changes to our controller or view in order for them to be supported. This provides us with the flexibility to easily evolve our application requirements in the future with a minimum of code changes.
Create Support
We’ve finished implementing the “Edit” behavior of our DinnersController class. Let’s now move on to implement the “Create” support on it – which will enable users to add new Dinners.
The HTTP-GET Create Action Method
We’ll begin by implementing the HTTP “GET” behavior of our create action method. This method will be called when someone visits the /Dinners/Create URL. Our implementation looks like:
[!code-csharpMain]
1: //
2: // GET: /Dinners/Create
3:
4: public ActionResult Create() {
5:
6: Dinner dinner = new Dinner() {
7: EventDate = DateTime.Now.AddDays(7)
8: };
9:
10: return View(dinner);
11: }
The code above creates a new Dinner object, and assigns its EventDate property to be one week in the future. It then renders a View that is based on the new Dinner object. Because we haven’t explicitly passed a name to the View() helper method, it will use the convention based default path to resolve the view template: /Views/Dinners/Create.aspx.
Let’s now create this view template. We can do this by right-clicking within the Create action method and selecting the “Add View” context menu command. Within the “Add View” dialog we’ll indicate that we are passing a Dinner object to the view template, and choose to auto-scaffold a “Create” template:
When we click the “Add” button, Visual Studio will save a new scaffold-based “Create.aspx” view to the “” directory, and open it up within the IDE:
Let’s make a few changes to the default “create” scaffold file that was generated for us, and modify it up to look like below:
[!code-aspxMain]
1: <asp:Content ID="Title" ContentPlaceHolderID="TitleContent" runat="server">
2: Host a Dinner
3: </asp:Content>
4:
5: <asp:Content ID="Main" ContentPlaceHolderID="MainContent" runat="server">
6:
7: <h2>Host a Dinner</h2>
8:
9: <%=Html.ValidationSummary("Please correct the errors and try again.") %>
10:
11: <% using (Html.BeginForm()) {%>
12:
13: <fieldset>
14: <p>
15: <label for="Title">Title:</label>
16: <%= Html.TextBox("Title") %>
17: <%= Html.ValidationMessage("Title", "*") %>
18: </p>
19: <p>
20: <label for="EventDate">EventDate:</label>
21: <%=Html.TextBox("EventDate") %>
22: <%=Html.ValidationMessage("EventDate", "*") %>
23: </p>
24: <p>
25: <label for="Description">Description:</label>
26: <%=Html.TextArea("Description") %>
27: <%=Html.ValidationMessage("Description", "*") %>
28: </p>
29: <p>
30: <label for="Address">Address:</label>
31: <%=Html.TextBox("Address") %>
32: <%=Html.ValidationMessage("Address", "*") %>
33: </p>
34: <p>
35: <label for="Country">Country:</label>
36: <%=Html.TextBox("Country") %>
37: <%=Html.ValidationMessage("Country", "*") %>
38: </p>
39: <p>
40: <label for="ContactPhone">ContactPhone:</label>
41: <%=Html.TextBox("ContactPhone") %>
42: <%=Html.ValidationMessage("ContactPhone", "*") %>
43: </p>
44: <p>
45: <label for="Latitude">Latitude:</label>
46: <%=Html.TextBox("Latitude") %>
47: <%=Html.ValidationMessage("Latitude", "*") %>
48: </p>
49: <p>
50: <label for="Longitude">Longitude:</label>
51: <%=Html.TextBox("Longitude") %>
52: <%=Html.ValidationMessage("Longitude", "*") %>
53: </p>
54: <p>
55: <input type="submit" value="Save"/>
56: </p>
57: </fieldset>
58: <% }
59: %>
60: </asp:Content>
And now when we run our application and access the “/Dinners/Create” URL within the browser it will render UI like below from our Create action implementation:
Implementing the HTTP-POST Create Action Method
We have the HTTP-GET version of our Create action method implemented. When a user clicks the “Save” button it performs a form post to the /Dinners/Create URL, and submits the HTML <input> form values using the HTTP POST verb.
Let’s now implement the HTTP POST behavior of our create action method. We’ll begin by adding an overloaded “Create” action method to our DinnersController that has an “AcceptVerbs” attribute on it that indicates it handles HTTP POST scenarios:
[!code-csharpMain]
1: //
2: // POST: /Dinners/Create
3:
4: [AcceptVerbs(HttpVerbs.Post)]
5: public ActionResult Create() {
6: ...
7: }
There are a variety of ways we can access the posted form parameters within our HTTP-POST enabled “Create” method.
One approach is to create a new Dinner object and then use the UpdateModel() helper method (like we did with the Edit action) to populate it with the posted form values. We can then add it to our DinnerRepository, persist it to the database, and redirect the user to our Details action to show the newly created Dinner using the code below:
[!code-csharpMain]
1: //
2: // POST: /Dinners/Create
3:
4: [AcceptVerbs(HttpVerbs.Post)]
5: public ActionResult Create() {
6:
7: Dinner dinner = new Dinner();
8:
9: try {
10:
11: UpdateModel(dinner);
12:
13: dinnerRepository.Add(dinner);
14: dinnerRepository.Save();
15:
16: return RedirectToAction("Details", new {id=dinner.DinnerID});
17: }
18: catch {
19:
20: ModelState.AddRuleViolations(dinner.GetRuleViolations());
21:
22: return View(dinner);
23: }
24: }
Alternatively, we can use an approach where we have our Create() action method take a Dinner object as a method parameter. ASP.NET MVC will then automatically instantiate a new Dinner object for us, populate its properties using the form inputs, and pass it to our action method:
[!code-csharpMain]
1: //
2: //
3: // POST: /Dinners/Create
4:
5: [AcceptVerbs(HttpVerbs.Post)]
6: public ActionResult Create(Dinner dinner) {
7:
8: if (ModelState.IsValid) {
9:
10: try {
11: dinner.HostedBy = "SomeUser";
12:
13: dinnerRepository.Add(dinner);
14: dinnerRepository.Save();
15:
16: return RedirectToAction("Details", new {id = dinner.DinnerID });
17: }
18: catch {
19: ModelState.AddRuleViolations(dinner.GetRuleViolations());
20: }
21: }
22:
23: return View(dinner);
24: }
Our action method above verifies that the Dinner object has been successfully populated with the form post values by checking the ModelState.IsValid property. This will return false if there are input conversion issues (for example: a string of “BOGUS” for the EventDate property), and if there are any issues our action method redisplays the form.
If the input values are valid, then the action method attempts to add and save the new Dinner to the DinnerRepository. It wraps this work within a try/catch block and redisplays the form if there are any business rule violations (which would cause the dinnerRepository.Save() method to raise an exception).
To see this error handling behavior in action, we can request the /Dinners/Create URL and fill out details about a new Dinner. Incorrect input or values will cause the create form to be redisplayed with the errors highlighted like below:
Notice how our Create form is honoring the exact same validation and business rules as our Edit form. This is because our validation and business rules were defined in the model, and were not embedded within the UI or controller of the application. This means we can later change/evolve our validation or business rules in a single place and have them apply throughout our application. We will not have to change any code within either our Edit or Create action methods to automatically honor any new rules or modifications to existing ones.
When we fix the input values and click the “Save” button again, our addition to the DinnerRepository will succeed, and a new Dinner will be added to the database. We will then be redirected to the /Dinners/Details/[id] URL – where we will be presented with details about the newly created Dinner:
Delete Support
Let’s now add “Delete” support to our DinnersController.
The HTTP-GET Delete Action Method
We’ll begin by implementing the HTTP GET behavior of our delete action method. This method will get called when someone visits the /Dinners/Delete/[id] URL. Below is the implementation:
[!code-csharpMain]
1: //
2: // HTTP GET: /Dinners/Delete/1
3:
4: public ActionResult Delete(int id) {
5:
6: Dinner dinner = dinnerRepository.GetDinner(id);
7:
8: if (dinner == null)
9: return View("NotFound");
10: else
11: return View(dinner);
12: }
The action method attempts to retrieve the Dinner to be deleted. If the Dinner exists it renders a View based on the Dinner object. If the object doesn’t exist (or has already been deleted) it returns a View that renders the “NotFound” view template we created earlier for our “Details” action method.
We can create the “Delete” view template by right-clicking within the Delete action method and selecting the “Add View” context menu command. Within the “Add View” dialog we’ll indicate that we are passing a Dinner object to our view template as its model, and choose to create an empty template:
When we click the “Add” button, Visual Studio will add a new “Delete.aspx” view template file for us within our “” directory. We’ll add some HTML and code to the template to implement a delete confirmation screen like below:
[!code-aspxMain]
1: <asp:Content ID="Title" ContentPlaceHolderID="TitleContent" runat="server">
2: Delete Confirmation: <%=Html.Encode(Model.Title) %>
3: </asp:Content>
4:
5: <asp:Content ID="Main" ContentPlaceHolderID="MainContent" runat="server">
6:
7: <h2>
8: Delete Confirmation
9: </h2>
10:
11: <div>
12: <p>Please confirm you want to cancel the dinner titled:
13: <i> <%=Html.Encode(Model.Title) %>? </i>
14: </p>
15: </div>
16:
17: <% using (Html.BeginForm()) { %>
18: <input name="confirmButton" type="submit" value="Delete" />
19: <% } %>
20:
21: </asp:Content>
The code above displays the title of the Dinner to be deleted, and outputs a <form> element that does a POST to the /Dinners/Delete/[id] URL if the end-user clicks the “Delete” button within it.
When we run our application and access the “/Dinners/Delete/[id]” URL for a valid Dinner object it renders UI like below:
| Side Topic: Why are we doing a POST? |
|---|
| You might ask – why did we go through the effort of creating a <form> within our Delete confirmation screen? Why not just use a standard hyperlink to link to an action method that does the actual delete operation? The reason is because we want to be careful to guard against web-crawlers and search engines discovering our URLs and inadvertently causing data to be deleted when they follow the links. HTTP-GET based URLs are considered “safe” for them to access/crawl, and they are supposed to not follow HTTP-POST ones. A good rule is to make sure you always put destructive or data modifying operations behind HTTP-POST requests. |
Implementing the HTTP-POST Delete Action Method
We now have the HTTP-GET version of our Delete action method implemented which displays a delete confirmation screen. When an end user clicks the “Delete” button it will perform a form post to the /Dinners/Dinner/[id] URL.
Let’s now implement the HTTP “POST” behavior of the delete action method using the code below:
[!code-csharpMain]
1: //
2: // HTTP POST: /Dinners/Delete/1
3:
4: [AcceptVerbs(HttpVerbs.Post)]
5: public ActionResult Delete(int id, string confirmButton) {
6:
7: Dinner dinner = dinnerRepository.GetDinner(id);
8:
9: if (dinner == null)
10: return View("NotFound");
11:
12: dinnerRepository.Delete(dinner);
13: dinnerRepository.Save();
14:
15: return View("Deleted");
16: }
The HTTP-POST version of our Delete action method attempts to retrieve the dinner object to delete. If it can’t find it (because it has already been deleted) it renders our “NotFound” template. If it finds the Dinner, it deletes it from the DinnerRepository. It then renders a “Deleted” template.
To implement the “Deleted” template we’ll right-click in the action method and choose the “Add View” context menu. We’ll name our view “Deleted” and have it be an empty template (and not take a strongly-typed model object). We’ll then add some HTML content to it:
[!code-aspxMain]
1: <asp:Content ID="Title" ContentPlaceHolderID="TitleContent" runat="server">
2: Dinner Deleted
3: </asp:Content>
4:
5: <asp:Content ID="Main" ContentPlaceHolderID="MainContent" runat="server">
6:
7: <h2>Dinner Deleted</h2>
8:
9: <div>
10: <p>Your dinner was successfully deleted.</p>
11: </div>
12:
13: <div>
14: <p><a href="/dinners">Click for Upcoming Dinners</a></p>
15: </div>
16:
17: </asp:Content>
And now when we run our application and access the “/Dinners/Delete/[id]” URL for a valid Dinner object it will render our Dinner delete confirmation screen like below:
When we click the “Delete” button it will perform an HTTP-POST to the /Dinners/Delete/[id] URL, which will delete the Dinner from our database, and display our “Deleted” view template:
Model Binding Security
We’ve discussed two different ways to use the built-in model-binding features of ASP.NET MVC. The first using the UpdateModel() method to update properties on an existing model object, and the second using ASP.NET MVC’s support for passing model objects in as action method parameters. Both of these techniques are very powerful and extremely useful.
This power also brings with it responsibility. It is important to always be paranoid about security when accepting any user input, and this is also true when binding objects to form input. You should be careful to always HTML encode any user-entered values to avoid HTML and JavaScript injection attacks, and be careful of SQL injection attacks (note: we are using LINQ to SQL for our application, which automatically encodes parameters to prevent these types of attacks). You should never rely on client-side validation alone, and always employ server-side validation to guard against hackers attempting to send you bogus values.
One additional security item to make sure you think about when using the binding features of ASP.NET MVC is the scope of the objects you are binding. Specifically, you want to make sure you understand the security implications of the properties you are allowing to be bound, and make sure you only allow those properties that really should be updatable by an end-user to be updated.
By default, the UpdateModel() method will attempt to update all properties on the model object that match incoming form parameter values. Likewise, objects passed as action method parameters also by default can have all of their properties set via form parameters.
Locking down binding on a per-usage basis
You can lock down the binding policy on a per-usage basis by providing an explicit “include list” of properties that can be updated. This can be done by passing an extra string array parameter to the UpdateModel() method like below:
[!code-csharpMain]
1: string[] allowedProperties = new[]{ "Title","Description",
2: "ContactPhone", "Address",
3: "EventDate", "Latitude",
4: "Longitude"};
5:
6: UpdateModel(dinner, allowedProperties);
Objects passed as action method parameters also support a [Bind] attribute that enables an “include list” of allowed properties to be specified like below:
[!code-csharpMain]
1: //
2: // POST: /Dinners/Create
3:
4: [AcceptVerbs(HttpVerbs.Post)]
5: public ActionResult Create( [Bind(Include="Title,Address")] Dinner dinner ) {
6: ...
7: }
Locking down binding on a type basis
You can also lock down the binding rules on a per-type basis. This allows you to specify the binding rules once, and then have them apply in all scenarios (including both UpdateModel and action method parameter scenarios) across all controllers and action methods.
You can customize the per-type binding rules by adding a [Bind] attribute onto a type, or by registering it within the Global.asax file of the application (useful for scenarios where you don’t own the type). You can then use the Bind attribute’s Include and Exclude properties to control which properties are bindable for the particular class or interface.
We’ll use this technique for the Dinner class in our NerdDinner application, and add a [Bind] attribute to it that restricts the list of bindable properties to the following:
[!code-csharpMain]
1: [Bind(Include="Title,Description,EventDate,Address,Country,ContactPhone,Latitude,Longitude")]
2: public partial class Dinner {
3: ...
4: }
Notice we are not allowing the RSVPs collection to be manipulated via binding, nor are we allowing the DinnerID or HostedBy properties to be set via binding. For security reasons we’ll instead only manipulate these particular properties using explicit code within our action methods.
CRUD Wrap-Up
ASP.NET MVC includes a number of built-in features that help with implementing form posting scenarios. We used a variety of these features to provide CRUD UI support on top of our DinnerRepository.
We are using a model-focused approach to implement our application. This means that all our validation and business rule logic is defined within our model layer – and not within our controllers or views. Neither our Controller class nor our View templates know anything about the specific business rules being enforced by our Dinner model class.
This will keep our application architecture clean and make it easier to test. We can add additional business rules to our model layer in the future and not have to make any code changes to our Controller or View in order for them to be supported. This is going to provide us with a great deal of agility to evolve and change our application in the future.
Our DinnersController now enables Dinner listings/details, as well as create, edit and delete support. The complete code for the class can be found below:
[!code-csharpMain]
1: public class DinnersController : Controller {
2:
3: DinnerRepository dinnerRepository = new DinnerRepository();
4:
5: //
6: // GET: /Dinners/
7:
8: public ActionResult Index() {
9:
10: var dinners = dinnerRepository.FindUpcomingDinners().ToList();
11: return View(dinners);
12: }
13:
14: //
15: // GET: /Dinners/Details/2
16:
17: public ActionResult Details(int id) {
18:
19: Dinner dinner = dinnerRepository.GetDinner(id);
20:
21: if (dinner == null)
22: return View("NotFound");
23: else
24: return View(dinner);
25: }
26:
27: //
28: // GET: /Dinners/Edit/2
29:
30: public ActionResult Edit(int id) {
31:
32: Dinner dinner = dinnerRepository.GetDinner(id);
33: return View(dinner);
34: }
35:
36: //
37: // POST: /Dinners/Edit/2
38:
39: [AcceptVerbs(HttpVerbs.Post)]
40: public ActionResult Edit(int id, FormCollection formValues) {
41:
42: Dinner dinner = dinnerRepository.GetDinner(id);
43:
44: try {
45: UpdateModel(dinner);
46:
47: dinnerRepository.Save();
48:
49: return RedirectToAction("Details", new { id= dinner.DinnerID });
50: }
51: catch {
52: ModelState.AddRuleViolations(dinner.GetRuleViolations());
53:
54: return View(dinner);
55: }
56: }
57:
58: //
59: // GET: /Dinners/Create
60:
61: public ActionResult Create() {
62:
63: Dinner dinner = new Dinner() {
64: EventDate = DateTime.Now.AddDays(7)
65: };
66: return View(dinner);
67: }
68:
69: //
70: // POST: /Dinners/Create
71:
72: [AcceptVerbs(HttpVerbs.Post)]
73: public ActionResult Create(Dinner dinner) {
74:
75: if (ModelState.IsValid) {
76:
77: try {
78: dinner.HostedBy = "SomeUser";
79:
80: dinnerRepository.Add(dinner);
81: dinnerRepository.Save();
82:
83: return RedirectToAction("Details", new{id=dinner.DinnerID});
84: }
85: catch {
86: ModelState.AddRuleViolations(dinner.GetRuleViolations());
87: }
88: }
89:
90: return View(dinner);
91: }
92:
93: //
94: // HTTP GET: /Dinners/Delete/1
95:
96: public ActionResult Delete(int id) {
97:
98: Dinner dinner = dinnerRepository.GetDinner(id);
99:
100: if (dinner == null)
101: return View("NotFound");
102: else
103: return View(dinner);
104: }
105:
106: //
107: // HTTP POST: /Dinners/Delete/1
108:
109: [AcceptVerbs(HttpVerbs.Post)]
110: public ActionResult Delete(int id, string confirmButton) {
111:
112: Dinner dinner = dinnerRepository.GetDinner(id);
113:
114: if (dinner == null)
115: return View("NotFound");
116:
117: dinnerRepository.Delete(dinner);
118: dinnerRepository.Save();
119:
120: return View("Deleted");
121: }
122: }
Next Step
We now have basic CRUD (Create, Read, Update and Delete) support implement within our DinnersController class.
Let’s now look at how we can use ViewData and ViewModel classes to enable even richer UI on our forms.
)
|
|