I was talking to a friend today, who's foremost a php developer, about his thoughts on Umbraco and he said "Well they're apparently working feverishly on the new version of Umbraco, which will be MVC... which i still don't know what that means, but I know you like it."
I ended up giving him a ground up explanation of ASP.NET MVC, so I'm posting this so he can link this to his friends and for anyone else who finds it useful. The whole goal was to be as simple as possible, not being focused on proper syntax.
Model-View-Controller (or MVC) is just a pattern that is used for handling UI interaction with your backend. In a typical web app, you can imagine the *M*odel as your database model, the *V*iew as your HTML page, and the *C*ontroller as the class inbetween.
MVC handles your web request different than your typical php/asp app.In your php/asp app, your url maps directly to a php/asp file that contains html, mixed with database access code and redirects.In an MVC app, your url route is mapped to a method on a class (the controller). The body of this method can do some database access and THEN decide which *V*iew (html/aspx page) should be displayed; putting the controller in charge and not the view... a clear seperation of concerns that provides better reusibility and generally promotes cleaner code.
Mysite.com, a quick example:Let's say you hit the following url in your application: http://www.mysite.com/Product/ShowItem?Id=4
To avoid tedious configuration, MVC uses a lot of conventions by default. For instance, the above url in your app would automatically make MVC search for a .net class with the name "Product" and a method named "ShowItem" based on the pattern of the url. So if you name things properly, your method would automatically be called when you entered the above url. Additionally, it would automatically map/hydrate the "int id" parameter that was in your querystring, matched by name.Product.cspublic class Product : Controller{ public ViewResult ShowItem(int id) { return View(); }}
From this point you can write the code in the body of this method to do some database access and then pass a "bag" (also known as the ViewData) of data to your chosen *V*iew (html page) to use for display. The view(html) ONLY needs to be worried about displaying the flattened data that it's been given in the best way it can; this allows the view to be reused throughout your application as *just* a view, and not be coupled to HOW the data for that view get's loaded..
Product.cspublic class Product : Controller{ public ViewResult ShowItem(int id) { var database = new Database(); var item = database.GetItem(id); ViewData["TheItem"] = item; return View(); }}
Again by convention, since the class' method name is "ShowItem", it'll search for a view named "ShowItem.aspx" by default, and pass the ViewData bag to it to use. ShowItem.aspx<html> <body> <% var item =(Item)ViewData["TheItem"] %> <h1><%= item.FullProductName %></h1> </body></html>
BUT WAIT! WHY DOES MICROSOFT HAVE TO DO THINGS SO DIFFERENTLY!?They aren't... here are some other frameworks you may have heard of that use the same pattern in a their own way:
Ruby On Rails
Grails
Spring MVC
Struts
Django
