7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial

Next lesson playing in 5 seconds

  • Overview
  • Transcript

3.2 Handling POST Requests

POST requests are fundamental to any web application—they are the mechanism for pushing data to the web server. You'll learn how to handle POST requests in this lesson, and you'll also learn about MVC's model binding feature.

3.2 Handling POST Requests

In the previous lesson, we created an action method and a view for displaying a form, so that we can post a new message. And you also learned a little bit about the Razor view engine as well. Well, whenever we filled out the form and submitted it, it looked like that nothing happened. We just saw the form again. But we know that something happened. We know that the create method executed, and all this method does is simply return the view. So that's definitely not what we want it to do. We wanted to take the information from the form, and process it, validate it, and eventually store it within our data store. So we could do something like this, we can check to see if the Request.Method is equal to GET, then we will simply return the View. And then we could check to see if the Request.Method is equal to POST. And if it is, then we can handle a POST request. And we can handle any type of request this way. And while this works, this really isn't the best approach, because we end up with a method that's doing more than what it needs to do. If a GET request is received, then it's going to display a form. If a POST request, then it's going to process data. It's doing different things and we don't want our action methods to do that. We want an action method to do one thing. And really, that's just like any other method on any other class. We want a method to do just one type of thing, and if we need slightly different behavior, then we write an overload. That's typically what we do. So let's do public IActionResult and let's call this Create. But this is going to handle a POST request. We are getting data back from the user. So we could have some parameters here, where we have our messageTitle, and then our messageContent. And then, of course, we want to do something with that data. For right now, we're just going to return the view. I'm going to set a break point here, so that when whenever we submit the form, we will hit this break point and then we can see what happens when this create method. Is executed. Now, whenever I run this, this actually isn't going to work, because while we can have overloaded methods within a controller, there's a small little rule that we have to follow. So, let's first of all go to message and then create, and we see this- an unhandled exception occurred while processing the request. And the exception is an ambiguous action exception. So basically the MVC framework knew that it needed to execute a create method. But it didn't need to know which one it needed to execute. So this is the problem, but it's an easy problem to solve. We have one method that handles GET requests so we can decorate that with HttpGet and then we have one that handles a POST request, and we can decorate that with HttpPost. And so now, the MVC framework knows what method is going to execute for what type of request. So if we run this again, I'm going to use Crtl+F, well, I can't use Ctrl+F5. We need to debug so that we can hit that break point. I'm going to press F5 and we will once again go back to message, create and then, whenever we fill out the form we are going to hit that break point, after we submit it. So let's say that this is a title and this is content. And whenever we submit it we hit this break point. Now I'm going to move my mouse cursor over these parameters and you can see that message title has a value of this is a title. And if I move over to messageContent, we see the value of that parameter, this is content. So the MVC framework is taking the information from our form and binding it to the parameters that we have in this method. But here the thing is, that the parameter names have to be the same name as the the fields in the form. Well let's stop debugging, and let's add some comments, because now that we have the title and the content to work with, we need to do some things with that data. So let's add a todo, and the first thing that we want to do is validate our data so that we can eventually store that. So let's add another todo, and store. Now we are going to eventually be using entity framework to store this information. That means that we need to create an object that's going to contain this information, so that we can save that object using entity framework. So we need a class to represent a message. So let's go to our models folder. Let's add a new class. And let's just call it Message. And we need two properties. Let's call those properties MessageTitle and MessageContent, the same things. So let's do prop and then Tab string, message, title. And then let's just copy and paste that, and we will change title to content. And then we can go back to the controller. We want to create one of these message objects. So we'll save our message equals new message, and we can use the initialization syntax. First of all, we need a using statement for our model's name space. And then we can say message title is equal to our message title, and then we would do the same thing for the content. So message content equals message content. That will give us our object that we will then store In our data store. And then instead of returning the view, what we would typically do is redirect back to someplace. And in this case, after we post a message, it would be nice to just go back to our list of messages, which would be the index. So instead of returning the view we will simply return, redirect. This is a method that creates a redirect result. There's another method that would actually be better for us to use, and that's redirect to action. We can specify the action that we want to redirect to. In this case, we want to redirect to the index action. If we wanted to redirect to an action on another controller, we could specify the controller as well. But we just want to go to the index of our message controller. This is a fairly typical process for a method that handles a post request. It's going to get the information. It will then validate that information. Then it will prepare it to be stored and then it will store it. This is so typical, in fact, that MVC has features that makes it easier on us. Like for example, instead of manually creating this object, we can let MVC do it for us. So instead of accepting two arguments here, the title and the content, we can just say that's, okay, the data coming back from our form is actually going to be a message object and we can just call that message, but we typically call it model. So that's now, we don't have to create this message object. It's going to automatically be done for us. So that all we have to do is validate the information and if it's correct, then we store in the data base, and then RedirectToAction. I'm going to set another break point here on the return statement, and let's run it. Let's submit the form, and then we will see that we have an actual message object that has the data from the form. We want to go to message, create once again. Let's just do foo and bar for the title and content, respectively. And now let's inspect this model object. You can see that it is not no, and its properties are set to the values that we supplied. The content is bar, and the title is foo. And so, now that we had the data tool to work with, the next thing we need to do is validate that data. And that is what we are going to do in the next lesson.

Back to the top