Today Scott Guthrie released first post from a series of post describing the new .NET model – MVC(Model View Controller).
It provides a structured model that enforces a clear separation of concerns within applications, and makes it easier to unit test your code and support a TDD workflow. It also helps provide more control over the URLs you publish in your applications, and can optionally provide more control over the HTML that is emitted from them.

In his post he shows how easily a simple E-Commerce application is build. The sample project is availabe in the new Visual Studio 2008 Project Templates.

Great plus for developers is that when created the solution includes also a unit test project!

You can use any unit testing framework (including NUnit, MBUnit, MSTest, XUnit, and others) with the ASP.NET MVC Framework. VS 2008 Professional now includes built-in testing project support for MSTest (previously in VS 2005 this required a Visual Studio Team System SKU), and our default ASP.NET MVC project template automatically creates one of these projects when you use VS 2008.

We’ll also be shipping project template downloads for NUnit, MBUnit and other unit test frameworks as well, so if you prefer to use those instead you’ll also have an easy one click way to create your application and have a test project immediately ready to use with it.

Understanding the Folder Structure of a Project

The default directory structure of an ASP.NET MVC Application has 3 top-level directories:

* /Controllers
* /Models
* /Views

As you can probably guess, we recommend putting your Controller classes underneath the /Controllers directory, your data model classes underneath your /Models directory, and your view templates underneath your /Views directory.

While the ASP.NET MVC framework doesn’t force you to always use this structure, the default project templates use this pattern and we recommend it as an easy way to structure your application. Unless you have a good reason to use an alternative file layout, I’d recommend using this default pattern.

Mapping URLs to Controller Classes

In most web frameworks (ASP, PHP, JSP, ASP.NET WebForms, etc), incoming URLs typically map to template files stored on disk. For example, a “/Products.aspx” or “/Products.php” URL typically has an underlying Products.aspx or Products.php template file on disk that handles processing it. When a http request for a web application comes into the web server, the web framework runs code specified by the template file on disk, and this code then owns handling the processing of the request. Often this code uses the HTML markup within the Products.aspx or Products.php file to help with generating the response sent back to the client.

MVC frameworks typically map URLs to server code in a different way. Instead of mapping URLs to template files on disk, they instead map URLs directly to classes. These classes are called “Controllers” and they own processing incoming requests, handling user input and interactions, and executing appropriate application and data logic based on them. A Controller class will then typically call a separate “View” component that owns generating the actual HTML output for the request.

Also here are his conclusion words:
Summary

This first blog post is a pretty long one, but hopefully helps provide a reasonably broad look at how all the different components of the new ASP.NET MVC Framework fit together, and how you can build a common real world scenario with it. The first public preview of the ASP.NET MVC bits will be available in a few weeks, and you’ll be able to use them to do all of the steps I outlined above.

While many of the concepts inherent to MVC (in particular the idea of separation of concerns) are probably new to a lot of people reading this, hopefully this blog post has also show how the ASP.NET MVC implementation we’ve been working on fits pretty cleanly into the existing ASP.NET, .NET, and Visual Studio feature-set. You can use .ASPX, .ASCX and .MASTER files and ASP.NET AJAX to create your ASP.NET MVC Views. Non-UI features in ASP.NET today like Forms Authentication, Windows Authentication, Membership, Roles, Url Authorization, Caching, Session State, Profiles, Health Monitoring, Configuration, Compilation, Localization, and HttpModules/HttpHandlers all fully support the MVC model.

If you don’t like the MVC model or don’t find it natural to your style of development, you definitely don’t have to use it. It is a totally optional offering – and does not replace the existing WebForms Page Controller model. Both WebForms and MVC will be fully supported and enhanced going forward. You can even build a single application and have parts of it written using WebForms and parts written using an MVC approach if you want.

Read the whole article