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

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.

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 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}.

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).

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”.

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.

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.

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.

About Ben Scheirman

Ben Scheirman is a software developer specializing in .NET. He has worked extensively on the web on various platforms and languages. Ben is a Microsoft MVP, Microsoft ASP Insider, and Certified ScrumMaster. When not programming, Ben enjoys speaking, blogging, spending time with his wife and five won... This author has published 4 articles on DotNetSlackers. View other articles or the complete profile here.