HowTo: Basics of ASP.NET MVC or why MVC?
A while ago I blogged about some ASP.NET MVC stuff, but why should I (and you) care about ASP.NET MVC?
ASP.NET MVC is a great and extensible framework for building web applications and is a alternative to the ASP.NET WebForms model.
Tell me more about "MVC"!
MVC stands for "Model-View-Controller", which is a very old (but still very useful) design pattern. This design pattern will split your application in 3 different parts ("model", "view", "controller"). "Seperation of concern" is one of it´s main benefits.
Short description of these parts:
- "Model": Represents your application data/model and has no(!) business logic
- "View": Just display the given viewdata (this could be a normal HTML page or JSON/RSS data)
- "Controller": The controller represents the business logic and create the view data and send it to a view.
A good example of an MVC application is the web browser.
What is so "bad" about ASP.NET WebForms?
ASP.NET WebForms include many abstractions for the web development. If you are a WinForms developer, you will feel comfortable with it, but if you started with PHP/JSP or just pure HTML and Javascript you will feel very uncomfortable.
The "viewstate" is one feature to hide the stateless nature of HTML, but it can make your web application very slow and makes you crazy. The "WebForms" model include a very complex lifecycle and it´s important to understand this to work with ASP.NET WebForms.
In my opinion it is too complex and the framework should embrace the nature of HTTP and don´t hide it.
Disclaimer: If you feel comfortable with WebForms, you have no reason to change to MVC – MVC is only on option.
What are the benefits of ASP.NET MVC
MVC is a very testable framework and you get full control of the rendering process. You can add functionality if you want, because MVC is very extensible and you can create a clean, DRY, testable web application.
Phil Haack (the program manager of ASP.NET MVC) did a great presentation at the PDC.
Things that you´ll maybe missing in MVC
Many ASP.NET controls use the postback-functionality. This function will not work well together with the MVC framework. Phil Haack did also 2 podcasts on HerdingCode and tell some thought about "the control story in MVC":
Part 1
Part 2
If you have questions, please add a comment (and if my english really suck please let me know 
). This blogpost should only provide basics – other posts are planned.
German
English
Dew Drop - November 25, 2008 | Alvin Ashcraft's Morning Dew said
am November 25 2008 @ 6:42 pm
[...] HowTo: Basics of ASP.NET MVC or Why MVC? (Robert Muehsig) [...]
HowTo: First steps with ASP.NET MVC | Code-Inside Blog International said
am November 26 2008 @ 12:57 am
[...] my last post I wrote about why you should take a look at ASP.NET MVC. With this blogpost I want to go a little [...]
Fresh Links November 26th, 2008 | News | Server-Side Magazine said
am November 26 2008 @ 9:33 am
[...] HowTo: Basics of ASP.NET MVC or why MVC? [...]
Interesting Finds: 2008.11.31 - gOODiDEA.NET said
am December 1 2008 @ 7:22 am
[...] HowTo: Basics of ASP.NET MVC or why MVC? – HowTo: First steps with ASP.NET MVC [...]
Simon said
am December 20 2008 @ 6:11 am
Umm, from what I’ve read the business logic should all be in the model (which could infact be a web service and not necessarily a just a database). For example, the ASP.NET MVC screencasts at http://www.asp.net/mvc/ and Rob Conery’s storefront all state that the controllers should be kept lightweight and really are there just for flow control. Apparently they should contain logic for directing between views and little more. Conversly, the model should contain the domain logic, constraints, data access and everything else because it is easy to test and easy to reuse (with other front ends).
Can you explain why you said in your post that the model should contain no(!) business logic?
Robert Muehsig said
am December 20 2008 @ 1:21 pm
You are right – the controller should be very light weight. But the word “model” is a bit unspecific. Model is for me only simple classes that contain your application objects, e.g. :
public class User
{
public string Name { get; set; }
}
I have 4 C# projects in my solution:
MyProject.Data for data access
MyProject.Services for business logic
MyProject.WebApp the MVC Website
MyProject.Model for my simple application classes like the user class
The last project contains no business logic – and in the MVC “Model” folder is nothing. The whole business logic is inside the services layer. That´s why I said, that in the model is no business logic.
See at Rob Conerys MVCStorefront project – it´s much like that