It seems that most of my development experiences evolve around the internet, and developing for it.  My first professional development was in WinForms in .NET 1.1, but I soon made the transition to WebForms.  My first full application (from design to deployment), was written using ASP.NET 2.0.  Now it seems that I’m making my way into another web application, and I’ve decided to take the MVC route.

I love learning new technologies, but I generally hate the getting up and running aspect to learning.  The internet is a big help, as well as my friends of Twitter and at community events.  However, MVC was one of those technologies where the people who really understood it weren’t really good at explaining what it is.  I’ve watched one introduction to MVC where the presenter started discussing dependency injection when talking about controllers.  Adding additional complexity to a topic with other topics is a recipe for disaster.

Adventures in MVC is going to be a series, but I’m not defining a part 1, 2, 3, etc.  Instead, I’m going to walk through my learning experience with ASP.NET MVC.  My big hope is that I’m going to be able to dumb down MVC enough that most people will be able to understand it out of the gate.  So let’s get started.

Disclaimer: Everything I’m going to discuss is my interpretation of what I’ve picked up and learned.  If I’m completely wrong, please feel free to leave a comment and set me straight.  It is not my intention to have incorrect information on this blog.  Thanks.

Let’s Talk About MVC

It seems that every MVC discussion I’ve read or listened to has started with a history.  While history is a good thing to understand, and the more you know, the more you’ll understand about design decisions made.  All you need to know is that it started with SmallTalk (which is an old programming language.  That’s the extent of my knowledge), and that it took hold and became popular among several languages.

You probably already know that MVC stands for Model View Controller.  Model is data, View is what the user sees, and controller is the middleman that binds a model to a view.  So what does that mean?

Breaking It Down

Let’s start with a page lifecycle.  A user requests a page.  The request goes to a controller.  The controller can look at the request and do several things.  The most common thing it does is return a view.

A view is a webpage.  At its most basic forum, it could be a static page.  The server doesn’t have to do anything to prepare a view for display.  However, static pages are boring, and if that’s all you have a need for, then maybe ASP.NET MVC is not for you.  When you need to make the data more dynamic, you can build your views around a model.

Models are easy to understand if you think about practical applications.  Take a shopping site, like Amazon (I’m not saying that Amazon uses MVC, but the result pages are good examples of what you would return with views).  Do a search for ASP.NET books.  The return list is a view.  If you’re a web forms developer, you’re probably thinking that a good solution is to use a Repeater or ListView.  MVC takes a different approach.  Instead of user controls, we would bind a model to our view.  In this example, the model would contain book results, along with information we would want to provide to the user.  When the view is built, it takes the information from the model and formats it in the way we want.  The controller is the glue that binds the two together. 

Where Do We Go From Here

I don’t expect anyone to have a full overview of MVC from the last section.  My goal is to simply make MVC less difficult to learn.  In the next entry, I’m going to discuss getting started with the ASP.NET project.

Oh, and before I get questions about this later, I will only be covering ASP.NET MVC 1.0 (not 2.0).  The reason being that my primary project right now is a MVC 1.0 application, so all my attention will be on that version. 

Please post any questions in the comments and I’ll do my best to answer them!

-Kevin