ASP.NET MVC Translated for the Web Forms Programmer (1 in a series)

It hasn't really been “What is MVC” for me. I understand what a model, view, and controller are. At least in concept. What I haven't been able to grasp is exactly what it means to me, a web forms developer to create an MVC application. Where would I put my objects? My classes? My methods? My utilities? What about my user controls and master pages? My web services? All these questions made it really intimidating for me to even consider making an MVC application on my own, so I left it to the professionals. Now I feel like I have a much better grasp on it, and it's time for ASP.NET MVC to be broken down “web forms style” so we can all understand a bit better.

 

The Model: Scott Gu's blog says the model is “the components of the application that are responsible for maintaining state “ For us this means our objects and our ORM classes. For me, that was usually a project on my solution called “Data.” That's it! Easy breezy.

 

The View: Ok, I want you to do something that may be hard, so brace yourself. Remember all your code behind files? Forget them. Pretend they aren't there. In fact, do away with your whole idea of a page and let's start over. Have you used master pages? If so, you're familiar with the idea of the “asp:Content” control. The MVC Views that are the equivalent of what we would consider aspx pages are the html controls within the “asp:Content” tag. There is no code behind, only valid html. This means a lot for you, lover of server controls, but we will talk about this later. Get it? An aspx page is now a view, there is no “aspx” and there is no “page” (at least how we understand them). Also included in our views are user controls and the master pages, and other things like RSS feeds. Pretty much anything that renders data to the user. This is making perfect sense for you I can tell, bear with me this will start to clear up.

 

The Controller: Ok, this is where your code behind went, kind of. Instead of methods you need to learn the term “Actions”, because that's what we now call our methods. Instead of putting our control and page manipulating methods in our aspx.cs files which caused postbacks and server calls, we are instead only manipulating objects in these controllers. The cool thing about these “Actions” is that they are fired with URLs in a very RESTful manner, even your parameters are included as part of these URLs. You can have URLs that populate a view, or a URL that does an Action like delete a record. Think of all the great JavaScript possibilities here.

So to recap, Controllers are where the methods (called “Actions”) live that manipulate your objects. These methods (“Actions”) are called by using URLs instead of server based events on your page or control.

 

 

Ok, so, now that we've made it this far let's discuss some of the huge changes that come with an MVC application. One of the first things to jump out is the lack of server controls. I got a little short of breath when I realized I was kissing goodbye my lovely repeaters and textboxes. However, fear not, my friends because this is all for the better. Gone are the bulky server controls and back are the crisp clean <input>, <button>, and <li> tags. For datasets? A simple foreach embedded in the html will iterate through that data and display it just like the server controls you've grown to love (and lean on like a crutch, no? Tell me I'm wrong). With such things as JSON and Jquery out there is no reason to use server controls, the client is so much faster. Remember, every time you do a postback a ninja dies.

 

Something else that is different for a lot of us that I touched on a little above is the lack of many different projects. The Models, the Views, and the Controllers all have their own folders in an MVC project. Also, there are folders for things like scripts, and style sheets, you can also add your own. I found the folder structure to be a bit different than what I am used to, but less bulky. Which makes me notice a bit of a theme here, are you?

 

Ok, so that's enough for this week. Next week we will dip in a little further to the “Actions,” their syntax and how the URLs are mapped. Also, how many controllers to a view? How many objects to a controller? Understanding MVC is not as hard as it seems and soon we will be writing our own applications as fast as you can say System.UI.WebControls.

 

 For more information about ASP.NET MVC here is a book written by Nick Berardi that should be very informative.

(Thank you to Peter Laudati for his talk on MVC this evening which cleared a lot of this up for me.)