ASP.NET Model View Controller (MVC) Framework divides an
application's implementation into three component roles:
- Models are the components of the application
that are responsible for maintaining state. Often this state is
persisted inside a database (for example: we might have a Product
class that is used to represent order data from the Products table
inside SQL).
- Views are the components responsible for
displaying the application's user interface. Typically this UI
is created off of the model data (for example: we might create
an Product "Edit" view that surfaces textboxes, dropdowns and
checkboxes based on the current state of a Product object).
- Controllers are the components
responsible for handling end user interaction, manipulating the
model, and ultimately choosing a view to render to display
UI. In a MVC application the view is only about displaying
information - it is the controller that handles and responds to
user input and interaction.
One of the benefits of using a MVC methodology is that it helps
enforce a clean separation of concerns between the models, views
and controllers within an application. Maintaining a clean
separation of concerns makes the testing of applications much
easier, since the contract between different application components
are more clearly defined and articulated.
The MVC pattern can also help enable red/green test driven
development (TDD) - where you implement automated unit tests, which
define and verify the requirements of new code, first before you
actually write the code itself.
A few quick details to share in the meantime about the ASP.NET
MVC framework:
- It enables clean separation of concerns, testability, and TDD
by default. All core contracts within the MVC framework are
interface based and easily mockable (it includes interface based
IHttpRequest/IHttpResponse intrinsics). You can unit test the
application without having to run the Controllers within an ASP.NET
process (making unit testing fast). You can use any unit testing
framework you want to-do this testing (including NUnit, MBUnit, MS
Test, etc).
- It is highly extensible and pluggable. Everything in the MVC
framework is designed so that it can be easily replaced/customized
(for example: you can optionally plug-in your own view engine,
routing policy, parameter serialization, etc). It also supports
using existing dependency injection and IOC container models
(Windsor, Spring.Net, NHibernate, etc).
- It includes a very powerful URL mapping component that enables
you to build applications with clean URLs. URLs do not need to have
extensions within them, and are designed to easily support SEO and
REST-friendly naming patterns. For example, I could easily map the
/products/edit/4 URL to the "Edit" action of the ProductsController
class in my project above, or map the
/Blogs/scottgu/10-10-2007/SomeTopic/ URL to a "DisplayPost" action
of a BlogEngineController class.
- The MVC framework supports using the existing ASP.NET .ASPX,
.ASCX, and .Master markup files as "view templates" (meaning you
can easily use existing ASP.NET features like nested master pages,
<%= %> snippets, declarative server controls, templates,
data-binding, localization, etc). It does not, however, use the
existing post-back model for interactions back to the server.
Instead, you'll route all end-user interactions to a Controller
class instead - which helps ensure clean separation of concerns and
testability (it also means no viewstate or page lifecycle with MVC
based views).
- The ASP.NET MVC framework fully supports existing ASP.NET
features like forms/windows authentication, URL authorization,
membership/roles, output and data caching, session/profile state
management, health monitoring, configuration system, the provider
architecture, etc.