Oh yes, there are lots of guides, tutorials and videotutorials out there explaining you (or trying to) what MVC is or how it works, but when you have been for many years developing with Visual Studio and Web Forms you feel like if you are missing something and feel uncomfortable. So I decided to write this guide for Web Forms developers getting into .Net MVC.
Breaking the Forms limit
First of all, forget it. If WebForms was called WebForms was for a reason, and the reason is (as you know) that it depends a bit too much on web forms. Every page in WebForms has a Form covering all the page, every postback, button, textbox is included into that form and, if you want to use two different forms for two different purposes, you just get used to it or you start hacking the system.
In MVC we have an open architecture, you have a server, you receive requests and you send back a response. You can respond what you please, there’s no need to use a form. Your pages in MVC may prefer to use a GET request instead than a POST, or to use an AJAX request (via GET or via POST), it doesn’t matter as forms are not needed anymore.
Example
Imagine you need a little login form at the header and another little search box in the sidebar. With WebForms you had to include those TextBoxes and Buttons inside the full Page Form, forcing the system to send a request to the server with ALL the page fields and data and viewstate. In MVC (well, being honest, in any other technology apart from .Net Webforms) you can just add those two little forms, one in the header and another in the sidebar, that will send a request with just the required amount of data to the server. Isn’t that better? Also, you can make the forms send the request to a different server page, so that the login will point to “mysite/login/” and the search to “mysite/search/” while WebForms was always pointing to “mysite/currentpage.aspx”.
<body>
<div id="MyHeaderSection">
<form id="loginForm" action="mysite/login/">
<input type="text"> <input type="submit">
</form>
</div>
<div id="content">
bla, bla, bla...
</div>
<div id="MySidebar">
<form id="searchForm" action="mysite/search/">
<input type="text"> <input type="submit">
</form>
</div>
</body>
Sayonara Page Lifecycle
Again, if you have been working with WebForms for a while I’m sure you know very well the Page_Init, Page_Load, Page_PreRender, Page_Render, etc. Forget about it. I’m not saying it wasn’t useful but with MVC you just get a request, decide what to load depending on it, decide what to use from coming data and decide what to send back.
With WebForms many controls were filled with data, so you accessed a TextBox.Text in the page and it had what the user had sent on posting, like having full control of the page from the server. Here the user is going to send whatever you included on the post/get request but once you have it you only receive that data as method parameters, so that any object you instantiate is a new clean object, you can fill it with what the user sent or not.
It may look less comfortable but there are many ways of making this pretty automatized once we get to explain MVC models.
Many more farewells: GridView, TextBox, UpdatePanels, …
As you are not going to continue accessing the page objects like in WebForms, all the objects you knew just do not exist in MVC. In MVC you paint a page, the page may send a request with some data, you get the data and decide what to send back, but what you receive and what you response is always very differentiated, so you don’t access a page element from the server side.
A good point here is the disappearance of UpdatePanels, which were very limited, huge, slow and ended up provoking many bugs (which is normal, as asynchronous requests are thought to work sending little requests and getting little responses and UpdatePanels were activating all the page life cycle). Now you can add some Ajax (maybe using jQuery) requests on your page and your server will get the request and send a response with no problem.
What is the Model-View-Controller?
Ok. Enough with the differences and farewells. Let’s explain what MVC is from a Web Forms Developer point of view. As you may have read out there, MVC consists in an architecture dividing responsibilities between three layers: model, view and controller.
The Controller is very similar to the back code of any .aspx page, except that it doesn’t have a page life cycle, so you have “actions” and you get a request and send back a response. Let’s see some examples:
//todo
As you can see, the controller just gets the requests and sends an answer. The response could be a View (read below), a string, json, xml, etc. and in case the user Action requires to access the database, the Controller will also access the Business or Data Layer to do so. Finally, in case we need to send back a bunch of values, we may prefer to use a Model to do so.
The Model is effectively a class, but a class designed for a concrete action and answer. Going back to my example at the beginning, the Action “Search” would return a list of results, so we would want a SearchModel with a property inside of it: List<Result>. But we may also want to paginate the results page, in that case we could need an int property called TotalRows (if we are paginating the server is not going to send back all the results but the ones in the current page) or the int CurrentPage.
Finally, the View is very similar to what we had in an .aspx page as the “design” file, where the html, css and javascript was placed. In MVC the connection between the View and the Server is not being done using .Net objects but an engine called Razor. With Razor, and once your set at the top of the View which Model you are going to use, you can use Intellisense to access the Model and its properties, using the Search example we could have a View like this:
//todo
You can see how we access the Model and its properties, how those properties are there to help with this action, the Search action.
MVC Request LifeCycle
So in case a User makes a Search a Controller will get that Action at mysite/search/ and then get the sent form (remember the search is a form). That form could effectively be a model too, we can declare a Model to have exactly the same values as the Search Form and on setting that the Search Action will receive that model, MVC will autonatically instantiate and set the property values for you, making your life very easy:
//todo
After that, our Controller may need to access the Business Layer to get the results and assign that to a Model, this time we are talking about the Model to send in the response. We will load the Model to be sent back with the results and assign it to the View to be returned.
Of course, that View has been developed with the idea of receiving a Model like that one, even though Views and Models are reusable in MVC architecture, so that you can use a Model in different Views or even make a View flexible to receive different Models (maybe using an interface here).
At the end of the day, the Controller responsibility is to determine what the User is trying to do, allow the Business Layer to decide about rules/permissions (you can add permissions and more logic in the Controller though, but it could take you to duplication of code so you may prefer to do this at the BL) and finally load the response data (in a Model, JSON, XML, just a string, …) and send it back in a View or without one. The Controller determines what to do with a request all the time, the rest, are just pieces to use and reuse as much as you need.
