ASP.NET MVC Introduction

Getting Started with the ASP.NET MVC
Framework
Published: 10/26/2009
By: Ben Scheirman

This article introduces the essential concepts of the ASP.NET MVC framework, dissects the MVC pattern,
and provides real-world examples to illustrate how it works.

Contents [hide]

1 Introduction
2 Picking Apart the Default Application
3 Creating the Project
4 Your First Routes
5 Running with the Starter Project
6 Your First ASP.NET MVC Controller From Scratch
7 Our First View
8 Ensuring the application is maintainable
9 Testing Controller Classes
10 Integrating with existing ASP.NET applications
11 Summary

About the book
This is an HTML version of the free Getting Started with the ASP.NET MVC
Framework (Green Paper - PDF). It has been published with the exclusive
permissions of Manning.

Written by: Jeffrey Palermo, Ben Scheirman, and Jimmy Bogard
Pages: 392
Publisher: Manning
ISBN-10: 1933988622
ISBN-13: 978-1933988627

Get 30% discount

DotNetSlacker readers can get 30% off the full print book or ebook at www.manning.com using the promo
code dns30 at checkout.

Introduction
Depending on how long you've been building web applications on the Microsoft platform, you'll relate to
some or all of the following pain. In the 1990's, developers built interactive websites using executable
programs that ran on a server. These programs (CGI was a common technology at the time) accepted a
web request and were responsible for creating an Html response. Templating was ad-hoc, and the
programs were difficult to write, debug and test.

In the late 1990's, Microsoft, after a brief stint with Htx templates and Idc connectors, introduced Active
Server Pages, or ASP. Active Server Pages brought templating to web applications. The server page was an
Html document with dynamic script mixed in. While this was a big step forward from the alternatives, the

world soon saw massive server pages with code indecipherable from the markup. In early 2002, along
came ASP.NET. ASP.NET was a complete shift for ASP developers because it moved all server page code
into a class file and replaced the Html markup with dynamic server controls in an Xml syntax. While
performance increased, and the debugging experience improved, new problems arose. The server-side
postback event lifecycle caused newsgroups to explode with activity as developer searched for the magic
event in which to add those two simple lines of code necessary to make the page work as needed.
Viewstate, while good in theory, broke down as the application scaled with complexity. Simple pages
broke 100KB in size, most of which was the Viewstate. Perhaps the greatest sin of the ASP.NET framework
was the tight coupling to everything in the System.Web namespace. There was no hope of unit testing any
code in the code-behind file, and today we see Page_Load methods that take several trees to print.

The ASP.NET MVC Framework has been introduced to simplify the complex parts of Web Forms while
retaining the power and flexibility of ASP.NET. The advantages of the ASP.NET request pipeline and
infrastructure stay the same, and ASP.NET MVC is provided to support ASP.NET applications using the
Model View Controller presentation pattern. Controlling code is kept in a class separated from hard
dependencies, and server pages have morphed into simple views, which are nothing more than Html
templates filled in with objects passed in by the controller. The post-back event lifecycle is no more, and
viewstate is no longer necessary.

In this paper, we will walk through your first lines of code built on top of the ASP.NET MVC Framework.
After this primer, you'll be ready for more advanced topics.

Throughout this paper, we will take you through creating a new ASP.NET MVC Framework web application
project, creating your first routes, controllers, and views. We will comb through the default application
and explain each part. Then we will extend it, and you will create your first controller and view. Before the
first example, let us explore the MVC pattern and the default application template provided with the
framework.

Picking Apart the Default Application
In this section, we will understand what the MVC pattern is and create our first ASP.NET MVC Web
Application. We will focus first on the controller because in the Model-View-Controller triad, the controller
is in charge and decides what model objects to use and what views to render. The controller is in charge
of coordination and executes first when the web request comes in to the application. The controller is
responsible for deciding what response is appropriate for the request.

The MVC pattern is not new. In fact, it is quite old. A core tenet of the MVC pattern is to separate control
logic from the view, or a screen. A view is responsible for rendering the user interface. By separating
domain logic and decoupling data access calls from the view, the user interface can now stay the same
even while logic and data access changes within the application. In figure 1, you will see a simple
diagram of the model-view-controller triad. Note that the controller has a direct relationship with the view
and the model, but the model does not need to know about the controller or the view. The web request
will be handled by the controller, and the controller will decide which model objects to use and which
view objects to render.

Figure 1: The model-view-controller pattern depicted

To begin, we will open up Visual Studio 2008 and create our project. The edition of Visual Studio 2008
makes some difference. You must be using Visual Studio 2008 Professional or a Team Edition sku that has
all of the Professional edition's functionality. The ASP.NET MVC Framework is supported with Visual Web
Developer Express as of the Service Pack 1 release, which added web project and class library support.
The ASP.NET MVC Framework builds on top of a web application projects, and while it is possible to make
it work with Web Sites, the development experience is optimized for use with Web Application Projects.

NOTE

You must already have the MVC Framework installed to proceed. The MVC Framework is an independent
release that builds on .Net 3.5 Service Pack 1. You can also deploy your application by including the MVC
Framework assemblies in the /bin folder of your web application if you need to run on a server with only
.Net 3.5 SP1 installed. If you are fond of Reflector (Lutz Roeder's Reflector: http://www.aisto.com/roeder
/dotnet/), you want to be sure to familiarize yourself with the System.Web.Mvc namespace in the
System.Web.Mvc assembly.

We'll begin in Visual Studio 2008 Professional by creating a new ASP.NET MVC Web Application project.
When you pull up the New Project dialog, make sure you have .Net Framework 3.5 selected. If you have
.Net Framework 3.0 or 2.0 selected, Visual Studio will filter the list, and you won't see the project
template for ASP.NET MVC Web Application. Now that you understand the basics of the pattern and how to
install the MVC framework, we will dive into our first project.

Creating the Project
Creating your first MVC Web Application project will be one of the simplest things you do as you move
through this paper. In Visual Studio 2008, when you have .NET Framework 3.5 selected as the target
framework, you'll see a new project template named "MVC Web Application." This is the project template
you will want to choose. The new project dialog will look like that shown in figure 2.

Figure 2: The MVC Web Application project is a project template added to the C# and VB.Net
sections of the New Project dialog. It is only available when you have .Net Framework 3.5
selected as the target framework.

We are going to be working with a C# ASP.NET MVC Web Application project. You have two options for
creating the project. When you click OK, the IDE will ask you about creating a test project. It is up to you
if you'd like it done for you or if you would rather create the unit test project yourself. If you are just
starting out, make sure you create a unit test project along with your web project. If you have an existing
solution and you are adding the ASP.NET MVC Web Application, you may choose to only add one project
and then add a Class Library project immediately afterward to support the unit tests. For this example, we
will move forward and choose the ASP.NET MVC Web Application with the test project. Figure 3 shows the
solution structure of the default Visual Studio template. Since this is not a beginners' paper, we will skip
the hand holding and go straight into the project.

Figure 3: The default structure for a web application project using the ASP.NET MVC
Framework uses convention for the placement of files.

The first thing you will notice is that the project comes with a few conventions. First, there is a folder, and
by convention, namespace, for controllers and views. You will also see a folder called "Models". This is for
presentation model classes. For any non-trivial system, you will want to have a project that contains your
domain model. The ASP.NET Framework documentation will tell you to put your domain model in the web
application project, but if you intend to have your non-trivial application have a long life, we recommend
you put only presentation concerns in the web application project. Lastly, in the default project, you will
be familiar with the Default.aspx file that is provided for you, and we'll discuss shortly why that is there.
First, we must understand the concept of a route.

Your First Routes
While previous version of ASP.NET mandated a strict convention for urls, the MVC framework provides a
mechanism to hand-craft urls. This concepts is called routing. Routing was released into ASP.NET in the
.Net Framework 3.5 Service Pack 1, and is available to all ASP.NET applications, not just those built with
the MVC framework. The Global.asax.cs file contains some routes that are provided with the MVC Web
Application project. Before continuing, we must define what a route is. A route is the complete definition
for how to handle a web request. With Web Forms, we have little control over this without resorting to url
rewriting. With Web Forms, the url of the web request is tightly coupled to the page handling the request.
If the page was named Foo.aspx in a folder named Samples, then the url was sure to be
http://mvccontrib.org/Samples/Foo.aspx. Many teams have resorted to url rewriting to wrangle some
control over the urls and how to satisfy each request. With the ASP.NET MVC Framework, routes are first

class citizens in the web application. We start with defining how we want our urls structured. The project
template gives us a few routes to start, shown in Listing 1.

Listing 1: Default routes for a new project. These are added by the project template.

Routes need to be defined as one of the first things when the web application starts up, so the project
template adds the routes to the Application_Start method in the Global.asax.cs file.

NOTE

We will follow long-standing best practices of Separation of Concerns and the Single Responsibility
Principle , or SRP, by moving the routes to a dedication location separated by an interface. We'll go more
into these principles later, but, in short, the responsibility (or concern) of the Application_Start method
is to kick off operations that must happen at the beginning of the application's life. The responsibility is
not to perform every bit of work that must happen on start. Any operations that must happen on
application start should reside in separate classes and merely be called in the appropriate order in the
Application_Start method.

Note that the url portion of the route is simply a matching mechanism for the request. If the url matches a
particular route, then we specify what controller should handle the request and what action method should
execute. You can create as many routes as you like, but one route is provided for you. This route has the
template, {controller}/{action}/{id}.

NOTE

This is a very generic route and could be used for many, many different web requests. Tokens are denoted
by the inclusion of {braces}, and the word enclosed in braces matches with a value the MVC Framework
understands. The most common that we'll be interested in are controller and action. This is the route we
will be using for the rest of the paper, so we will be content with a url in the form of
http://mvccontrib.org/controllername/actionname. The basic RouteHandler is an instance of IRouteHandler
and we'll use MvcRouteHandler most of the time. We have complete control and could provide our own
implementation of IRouteHandler if we wished.

Before we spin up our first controller, let's examine what is different about the web.config file in an MVC
Web Application project. The differences are easy to spot. Just look for "routing" or "mvc". One difference
we see is that a new IHttpModule is registerd in the config file. Here, we see the UrlRoutingModule in
listing 2.

Listing 2: Unique addition to the web.config file. The rest of the web.config file is standard for
.Net 3.5.

The UrlRoutingModule evaluates a request and sees if it matches a route that is stored in the RouteTable.
If the route matches, it overrides the default handler (IHttpHandler) for the request so that the MVC
Framework handles the request. We are going to examine our first controller as a means to handle a route
for the url /home. In the next section you will see how all the pieces of the starter project fit together.

Running with the Starter Project
This will be a very short section. We are going to move through the starter project very quickly looking at
each piece of provided code. Each serves as an example of how to fit code together when writing an
application with the presentation layer powered by the ASP.NET MVC Framework. Before looking at code,
run the web application by pressing CTRL+F5, and you should see something like that in figure 4.

Figure 4: The starter project comes will a basic layout and css.

Notice that the starter project includes some navigation, a login, and some content. The provided CSS
provides some simple formatting on top of XHTML. Notice the url in the address bar is /Home. This url
does not have an extension, so if you are running on IIS 6, you must either add a wildcard mapping or
install an ISAPI filter that provides this functionality.

Since you are already familiar with the ASP.NET request pipeline, we will briefly move through how this
request makes its way to an ASP.NET MVC controller. The following outlines how the request moves
through ASP.NET, to the controller and through the view:

1. Request comes in to /Home.
2. IIS determines the request should be handled by ASP.NET.
3. ASP.NET gives all HttpModules a chance to modify the request.
4. The UrlRoutingModule determines that the url matches a route configured in the application .
5. The UrlRoutingModule assigns the MvcHttpHandler as the handler for the request.
6. The handler finds the controller based on the route {controller}/{action}/{id}.
7. The HomeController is found, and its Execute method is invoked.
8. The HomeController invokes the Index action.
9. The Index action adds some objects to the ViewData dictionary.
10. The HomeController invokes the ActionResult returned from the action, which renders a view.
11. The "index" view in the views folder displays the objects in ViewData.
12. ASP.NET renders the response to the browser.

The above is the simplified life of a request handled by the ASP.NET MVC Framework. If you are curious
about more details, you can browse the source code, which is available at http://www.codeplex.com
/aspnet. The above steps are sufficient for understanding how to write code based on the ASP.NET MVC
Framework. You have already seen the route used in the starter project. Let us look at the HomeController
next, as shown in listing 3.

The first thing you should notice is how simple and clean the controller looks. There is no generated code
to wade through, and each action method returns an object derived from ActionResult. Notice how this
controller derives from System.Web.Mvc.Controller. You will probably find this base class adequate, but
there are some other base classes to choose from in the MvcContrib project, and as time goes on, the
community will make available many more. Inside each action method, you will want to put some objects
into a dictionary called ViewData. This dictionary will be passed to the view upon rendering. The
controller should provide any objects the view requires in this ViewData dictionary. In the starter kit, the
objects are simple strings, but in your application, you will use more complex objects. Each other these
actions returns the result of the View() method, which returns a System.Web.Mvc.ViewResult object. This
ActionResult will likely be a common result given than your applications will have many screens. Next, let
us take a look at the view shown in listing 4, which can be found in the project in the following path:
/Views/Home/Index.aspx.

Listing 3: A simple view

The view shown in Listing 4 is the one rendered in the browser screenshot shown earlier. The only
modification we make from the starter project was to jettison the code-behind file. Since the view uses
the WebForms templating engine, it has code-behind available to it, but for serious business applications,
we find that filling code-behind with logic leads to less than maintainable applications; therefore, we
recommend the use of views without code-behind. This view uses a master page, which is called a
"layout" in MVC speak. This layout can be specified by the controller for compatibility with many view
engines, but some view engines support the view specifying the layout, such as is the case with the
WebForms view engine, which is the default in the starter kit. View engines will be covered in more depth
later, but some alternatives can be found in the MvcContrib open source project. In the body of this view,
the server side tags are pulling objects out of ViewData and rendering them in line with html. The

responsibility of the view is to take objects in ViewData and render them for consumption by the user. The
view doesn't decide what to render. The view only decides how to render. The controller has already
decided what to render.

In listing 5, examine the code of the layout. You immediately see that it is just a plain old master page
without a code-behind (code-behind removed by the author).

Get 30% discount


Listing 4: The starter project layout

The master page here is in charge of navigation. It uses view helpers to render the links. View helpers are
available for most common dynamic needs and for all form elements. More view helpers are available in
MvcContrib, and third-party component vendors will not be far behind in offering commercial view
helpers.

Now that you have seen how the code in the starter project fits together, let us see how to test the
controller code. View code will still need to be tested with a tool like Selenium or Watir, but controller
code can easily be test-driven since it is decoupled from the view and the ASP.NET runtime. The following
code listing is a unit test for the starter project. The starter project uses MSTest as the unit testing
framework, but these authors recommend using NUnit. If you are just starting out in automated testing,
any mainstream framework will do.

Listing 6 shows an MSTest test method included in the default test project template.

Listing 5: The unit test for the Index action is fairly simple.

Believe it or not, we have completely walked through the ASP.NET starter project, and you know the
basics of the new framework. Working with the code directly along with reading this text will give you a
great understanding of this technology. In fact, now is a great time to open you IDE.

Your First ASP.NET MVC Controller From Scratch
Let's take a looking at listing 7 to understand how a web request is processed by the controller. Note the
only requirement is to implement the IController interface.

Listing 6: Our first controller

The first thing we notice is the IController interface. As with everything in the ASP.NET MVC Framework,
there is very little the developer must do to plug into the MVC Framework. In the case of the controller,
the only. . . I'll say it again. . . only requirement is that the class implement the IController interface. This
interface comes with a single method, Execute. How you handle the request is entirely up to you. In the
following controller, we are intentionally violating all principles of sensible programming as well as the
Law of Demeter in order to get the message "Hello World" written out to the screen as quickly as possible.
In this case, I've chosen not to make any use of a view. Rather, I'm formulating the html markup and
directly outputing it to the response stream. We'll run the sample and note the output in figure 5.

Figure 5: This figure shows our web application running in the browser. Note the simple url

and the absence of “.aspx”.

NOTE

Along with the MVC Framework, Microsoft has wrapped some of the ASP.NET code and provided abstract
classes to some of the key APIs such as HttpResponseBase, HttpRequestBase, and most importantly,
HttpContextBase. A quick google search will reveal how many people have had trouble testing against
HttpContext because of its sealed and static members. Providing abstract classes for these key APIs
loosens the coupling to them and, therefore, increases testability.

Listing 7 shows the absolute and complete power you have when creating a controller class. It's very
important to have complete control; however, most of the time, we are working in a handful of scenarios
that repeat over and over. For these scenarios, the product provides a base class that gives extra
functionality of which we can take advantage. The base class for these common controllers is
System.Web.Mvc.Controller. It implements the Execute method for us and uses the route to call different
action methods depending on the url and the route defaults.

NOTE

System.Web.Mvc.Controller is only one option to choose as a base class for your controllers. Often it is
appropriate to create your own Layer Supertype for all of your controllers. This type can inherit from
System.Web.Mvc.Controller, implement IController or derive from any other controller base class, such as
the ones provided in the MvcContrib project.

Our first use of the Controller base class will only need one action method, and we'll go with the
convention for the default action and call it Index. We'll observe listing 8 to see what our controller looks
like while leveraging the Controller base class. This base class implements the IController interface for us
and provides the capability of invoking action methods based on the current Route.

Listing 7: Using the Controller base class

Notice that the Index action method is all that is necessary for this controller to be web-callable. Simple
content action methods need not return ActionResult. Returning any other type will result in that object
being rendered as content to the response stream.

If we point our browser to /HelloWorld2, we'll see that our controller sends exactly the same response to
the browser as shown in figure 6. Now that we know how to craft a controller, we will explore our first

view.

Figure 6: Notice the web page has the same output as before. The end result is the same even
though the controller implementation has evolved.

Our First View
Recall that the ASP.NET MVC Framework uses a convention for locating views. The convention is to find an
.aspx file in a directory tree that matches /Views/controllername/actionname.aspx. In our next example,
we will modify our controller a bit by calling a method on the Controller base class called RenderView.
We'll set the model, which is a string with the text, "Hello World", to an entry in the ViewDataDictionary
object on the ViewData property of the Controller base class. This ViewDataDictionary instance will be
forwarded to the view. Although ViewData is a ViewDataDictionary we recommend you only depend on the
IDictionary<object, object> interface if you are replacing the view engine. Below in our example, we see
that our action returns ActionResult instead of void. After an action method returns, the ActionResult
executes to perform the appropriate behavior, which is rendering a view in this case. Examine listing 9 for
the current implementation of our controller. ViewData contains the object that will be forwarded on to the
view. The RenderView method also supports passing a single object to the view that is then accessible via
ViewData.Model, but in practice, this is only useful in simple applications.

Listing 8: Using a view to render the model

If you are following along with this example, you'll want to create a HelloWorld3 folder inside /Views in
your project as shown in figure 7.

Figure 7: The “HelloWorld3” folder must reside inside the /Views folder in order to be properly
located. This is a convention used by the default view factory. You can override this behavior
if you wish.

Next, add a new item to the project inside /Views/Helloworld3. We'll select the MVC View Page item
template and name it LooseHello.aspx. The name is important since in our HelloWorld3Controller we are
rending a view named LooseHello. Your project should show similarly to figure 8 above. LooseHello.aspx
resides in the HelloWorld3 folder.

Figure 8: Adding the view to our project. MVC View Page is available in “Visual C#/Web”.

Our markup with the view will be very simple. After all, this application is so trivial that all it has to do is
output "Hello World3" to the screen in big text. We'll use the <% server side operators to pull out our
model (which is a string) from the ViewData dictionary and render it to the screen. Listing 10 has our
markup for the view. Notice that the view does not have a codebehind file. You can use one if you wish,
but it is not necessary. The base class is System.Web.Mvc.ViewPage. This is a very important difference
from Web Forms. Although Microsoft will likely recommend the use of codebehind, we recommend against
codebehind files. The presence of this file is an ongoing temptation to violate Separation of Concerns by
putting controlling logic in the view. When working with only a markup file, we quickly recognize if the
view becomes bloated. In that case, we can easily refactor the controlling logic back to the controller and
then pass appropriate objects inside ViewData.

Listing 9: A simple view. Note how we extract the object passed from the controller from the
ViewData dictionary.

The flow from our controller to our view is very, very simple. The controller designates one or many
objects to be forwarded to the view, declares the name of the view, and the MVC Framework will locate
the view, instantiate it, push in the ViewData, and have the view render itself to the response stream. The
ViewPage base page fully supports rendering, but viewstate, postbacks, and the server-side post-back
events no longer happen. Rendering events still fire. The view's responsibility is to transform objects
passed to it into html. This is a very key part of the Separation of Concerns that Microsoft is focusing on
for this product.

The controller does not know how the view is doing the formatting. The only point of coupling is that the

controller names the view. It does not matter that the System.Web.Mvc.WebFormViewEngine is executing.
The same controller could function quite well with an NVelocity view (supported in MvcContrib). For now,
we will forward "Hello World3" to the view, and figure 9 shows the rendered page. This example has
shown how to get some examples working, but there are maintenance concerns you should be aware of
while building an application with this framework.

Figure 9: Although we are using a complete view, the output is the same as previous
examples, except now, we have a full html page and not just an html fragment.

Ensuring the application is maintainable
You might have cringed when you saw that the domain model object was being pushed into an IDictionary
with a string key as the way to identify the object in the view. .Net has conditioned us to want everything
to be strongly-typed, so string identifiers are sometimes viewed as a negative. That point is subjective
and controversial, and you have several options depending on your preferences. The use of an
IDictionary<object, object> for ViewData is the default mechanism in the Controller base class. As the
number of objects forwarded to the view increase, it is easy to create some helpers in the view to avoid
casting operations everywhere. For our next example, we will make a small change to our controller and
view to enable a strongly-typed reference. Listing 11 shows our controller discarding the use of the
IDictionary<object, object> and passing domain model object directly to the RenderView method. This
works well for simple views.

For composed views, a more flexible container, like IDictionary is necessary. For the view, again, since
our domain model is a string, the only difference is the lack of the need to call ToString() in the view.
Note in listing 11 the simplified rendering. If I want to call ToLower() to ensure the text was lowercase,
I'd get intellisense and API checking. For this view, we are also using a master page, which provides a
layout for the rendered page. The layout is declared by the controller in the RenderView() call.

Listing 10: Passing in the presentation model to the RenderView method

Listing 11: Strongly typed view with layout. You are probably familiar with this master page
usage.

One key factor in make the viewdata strongly-typed is the base class we choose for the view. Note in
listing 12 that we have chosen System.Web.Mvc.ViewPage<T>. The generic base class allows us to
strongly-type the ViewData property because the ViewData property is of type T.

This capability exists, but, as mentioned before, we recommend against using the ViewPage<T> base
class since this technique does not scale well to complex and composed views. Keep reading. We will
recommend an alternative approach for composed views. Listing 13 shows the syntax for using the
ViewPage with a strongly-typed model.

Listing 12: Strongly-typed codebehind

If you have a keen eye, you noticed how our view now makes use of a MasterPage without actually
declaring which masterpage to use. From the controller's point of view, this is a layout, and the controller
can choose the layout, or it can be a detail of the view. It is up to you, but not all view engines suppor the
view specifying the layout.

Layouts function exactly the same as web forms for templating, but the server side postback and viewstate
mechanism are irrelevant. Rendering is the only responsibility of the view and the layout. Listing 14
shows our layout, which outlines the structure for the page. Notice the layout declares
System.Web.Mvc.ViewMasterPage as the base type (and codebehind has been removed).

Listing 13: The layout for our view. The purpose is to provide the layout structure for the
view. Be sure not to put any behavior here.

If we point our browser to /HelloWorld4, we see our strongly-typed view and layout in action. To make it
stand out, we have given it a strong, red border as shown in figure 10. As mentioned before, all future
views will not use the ViewPage<T> base class.

Figure 10: This is our final view, complete with layout, strong typing and a little CSS to spice
it up.

Congratulations! You've created your first controller, and it handles its responsibility perfectly. From this
point forward, we will not cover every small step of developing with the MVC Framework. If you are
reading this paper, you are already well-versed in ASP.NET, so we will merely be covering the items that
are new with the ASP.NET MVC Framework. We will be using best practices and advanced software
development techniques. The first very important one is unit testing. Because the MVC Framework allows
us to keep our screen controllers separated from the views, we can now test the presentation logic very
easily. We consider testing part of getting started with the MVC Framework.

Testing Controller Classes
Turn back to the Visual Studio solution to the unit test project that already exists there. Because Visual
Studio does not come with NUnit, you will need to add your own reference to NUnit or your unit testing
framework of choice. Because MSTest now comes in the Professional sku, the project will come with a
reference to MSTest. We have removed that reference and opted for the more widely used tool, NUnit. We
have created a class named HelloWorld4ControllerTester to house the unit tests that verify it functions
correctly. See in figure 11 that we are grouping controller unit test fixtures in a Controllers folder. We will
continue to group like fixtures.

Browse through the following code listings. You will notice that we have created stubs for several classes
that the controller needs to function. This unit test example is the simplest one we will see in this paper.
Listing 15 depicts the NUnit test fixture for HellowWorld4Controller.

Figure 11: In your unit test project, after adding a reference to nunit.framework.dll, you are
ready to add a test fixture.

Listing 14: Unit test fixture with NUnit. The tests are pretty simple at this point.

Let's examine our very simple unit test inside HelloWorld4ControllerTester. Our test is
IndexShouldRenderViewWithStringViewData. We create an instance of the class under test,
HelloWorld4Controller. We then call our Index method capturing the ActionResult returned. Our test
expects it to be a ViewResult instance, so we cast it as such. If the code returns the wrong type, our test
will fail appropriately. At the end of the test, we easily assert our expectations. Unit tests normally follow
an Arrange, Act, Assert flow, and this test is a perfect example of that. This was a very simple unit test.
Figure 12 shows the test being run with UnitRun from JetBrains. UnitRun is also a feature of Resharper.

Figure 12: When we run this unit test using JetBrains Resharper, we see that it passes like we
expect.

Creating automated unit tests for all code and then running these tests with every build of the software
will help ensure that as the application scales with complexity, the software continues to be maintainable.
Typically as an application grows it becomes more difficult to manage. An automated test suite helps
counter that natural tendency for entropy. Fortunately, it is very easy to test controllers with the MVC
Framework. Make sure that as you are writing your unit tests, they do not call out to any database or web
service. To keep your unit tests fast, they must not call out of process. It is very reasonable to run a build
containing 2000 automated tests in five minutes; however, if all of your tests involve a database, your
build will take much longer, and your tests will be so hard to maintain that you will neglect them.

Integrating with existing ASP.NET applications
Can we create some screens that leverage the ASP.NET MVC Framework while others continue to work
using web forms? Of course we can. They can run side-by-side until the entire application is MVC. Using
the MVC Framework is not an all-or-nothing proposition. It is reality that there are many, many ASP.NET
applications in production using Web Forms. In the case where the software team wants to migrate the
application from Web Forms to ASP.NET MVC, it is possible to do a phased migration and run the two
side-by-side in the same AppDomain when necessary. ASP.NET MVC does not replace core ASP.NET
libraries or functionality. Rather, it builds on top of existing ASP.NET capabilities. The UrlRoutingModule
that we registered in the web.config file causes an incoming url to be evaluated against the existing
routes. If a matching route is not found, ASP.NET will continue on and use Web Forms to fill the request,
so it is pretty simple to mix and match features during a migration or for the purpose of application
extension.

While WebForms is not going away any time soon, we believe that controllers, actions, and views will be
the preferred way to write ASP.NET applications going into the future. Although Microsoft will continue to
support both options, we believe that the MVC Framework will be favored over WebForms much like we
see C# favored over VB in documentation, industry conferences, and technical books.

Get 30% discount


Summary
We have now seen how easy it is to get started with the ASP.NET MVC Framework. You now know how to
add a route to the application. The route defines what should happen with a given url. The route will
specify the default controller and action. Once the controller invokes, an action method is in charge of
determining what should be passed to the view for the given request. The controller is completely in
charge of what to display and is responsible for passing one or many objects to the view for conversion
into html. The view takes the objects passed and formats the objects using a view template. The view
does not make any decisions about the objects passed but merely formats them for display. This
separation of concerns contributes to a more maintainable application than what we've seen with Web
Forms.

Please visit the link at the below url for any additional user comments.

Original Url: http://dotnetslackers.com/articles/aspnet/Getting-Started-with-the-ASP-NET-
MVC-Framework.aspx

ASP.NET MVC Introduction

Recommended

More Related Content

What's hot (20)

Similar to ASP.NET MVC Introduction (20)

ASP.NET MVC Introduction