Afternoon of ASP.NET MVC [16 June] (free Headspring event)

Next Tuesday, 16 June 2009 from 1pm to 5pm, Eric Hexter and Jeffrey Palermo will be facilitating a 4-hour (free) workshop on ASP.NET MVC.  This is the second event of this kind, and we intend to continue partnering with Microsoft to provide this kind of free technology training.

Last time the event was held, the room was completely full, so it is very important that you RSVP here.

Go here for all the details.

With the new version of ASP.NET…

ASP.NET MVCDevelopers can easily leverage the Model-View-Controller pattern in ASP.NET applications. Pulling logic away from the UI and the views has been difficult for a long time. The Model-View-Presenter pattern helps a little bit, but the fact that the view has to delegate to the presenter makes the UI pattern difficult to work with.

Headspring has been using ASP.NET MVC since the original prototype and has presented on the topic at local conferences as well as Microsoft TechEd. Headspring employees are responsible for a book on ASP.NET MVC, as well as MvcContrib, CodeCampServer, and several community Solution Templates. This workshop offers the opportunity to share the experience using the ASP.NET MVC Framework on real-world systems.

On Tuesday, June 16, from 1PM to 5PM, we would like to show you some of what we know. Please join us for an afternoon of MVC at the Microsoft Technology Center. Register in advance of attending.

The instructors are Eric Hexter and Jeffrey Palermo.

Training located in Austin, Texas (1:00 p.m. to 5:00 p.m.)
Microsoft Corporation
9606 N Mo Pac Expy # 200
Austin, TX 78759
(512) 795-5300

Input Builders for ASP.NET MVC series continues from Eric Hexter

Eric Hexter is continuing his multi-part series on Opinionated Input Builders.  He’s on a role!
They are expression-based, meaning they eliminate the need for most strings for Html Helpers in your views.
They look like this:

And the output on the screen is:

First Name*: ______________ ex:John
Eric is collecting feedback and opinions now because this will eventually go into MvcContrib.  It is being tested on a few small, low-risk projects at Headspring Systems to ensure that they suit a general need.

Input Builders for ASP.NET MVC in the works

Subscribe to my feed here:


Eric Hexter has started a multipart series on Opinionated Input Builders.  They are expression-based, meaning they eliminate the need for most strings for Html Helpers in your views.  They look like this:



And the output on the screen is:

First Name*: ______________ ex:John
Eric is collecting feedback and opinions now because this will eventually go into MvcContrib.  It is being tested on a few small, low-risk projects at Headspring Systems to ensure that they suit a general need.

ASP.NET MVC HttpModule Registration Under IIS Integrated Mode vs. Classic Mode

Subscribe to my feed here:


In many applications, I find the development team needs to have some bit of configuration code run at the very beginning, before any other code.  In a web site on ASP.NET, we have the Global.asax file that has an Application_Start method.  In an ASP.NET MVC app, we register routes and do other things before the first request is served by the application.  One of the common start-up tasks my teams need to do is configuration NHibernate:  setting up the configuration, creating the SessionFactory, etc.  Because NHibernate is an infrastructure concern, one of our standards is that only the Infrastructure project has a reference to NHibernate.dll.  This presents a special need on the UI project because the UI project is not allowed to reference the start-up code explicitly. 


To get around this, we use an IHttpModule implementation to do start-up configuration.  This module lives in the Infrastructure project off to the side, and we add it to the web.config file so that the ASP.NET runtime will call it.  Here is a sample start-up module for NHibernate.  Note that the only purpose is to catch a time before the first request, and you can slide in any start-up code:

public class NHibernateModule : IHttpModule
private static bool _startupComplete = false;
private static readonly object _locker = new object();

public void Init(HttpApplication context)
context.BeginRequest += context_BeginRequest;
context.EndRequest += context_EndRequest;

private void context_BeginRequest(object sender, EventArgs e)
new DataConfig().StartSession();

private void context_EndRequest(object sender, EventArgs e)
new DataConfig().EndSession();

private void EnsureStartup()
if (!_startupComplete)
lock (_locker)
if (!_startupComplete)
new DataConfig().PerformStartup();
_startupComplete = true;

public void Dispose()


We are using double-checked locking to ensure we only perform the start-up code once.  This module is registered in the web.config here:

<add name="StartupModule" type="Infrastructure.NHibernateModule, Infrastructure, Version=, Culture=neutral"/>

This works fine if IIS7 is set to Classic mode.  As soon we go to Integrated Mode, which is recommended on IIS7 for ASP.NET MVC, this module registration doesn’t work.  Instead, we use the system.webServer node as shown below:

<modules runAllManagedModulesForAllRequests="true">
<add name="StartupModule" type="Infrastructure.NHibernateModule, Infrastructure, Version=, Culture=neutral"/>

There you have it.  Works like a charm on IIS7 in Integrated Mode.

ASP.NET MVC 2.0 and VS 2010 plan now public

Subscribe to my feed here:

Phil Haack has shared some of the plans in the works for ASP.NET MVC 2.0  After the initial release, the team didn’t slow down at all.  They have a great line-up, and I’m going to share it with you in this post.  Before some of the feature areas, I wanted to share some of what the team has stated are the targets for the v2.0 release.

Earlier this year, I made the prediction that within 2 years, the majority of new ASP.NET projects would choose the MVC route instead of WebForms.  I believe that the targeted scenarios in the 2.0 roadmap support my prediction.

With the 1.0 release, the target from Microsoft is to provide another options for ASP.NET developers.  They stand by both IHttpHandler implementations and pledge to support and enhance both going forward.  As of right now, there are some legitimate concerns about using ASP.NET MVC on certain teams where the skillset of the developer is heavily focused on designer development and UI controls.  Also, there are some scalability scenarios that require an add-on or custom development.

Enterprise Ready

ASP.NET MVC 2.0 has a goal of being enterprise ready.  They are targeting the enterprise with some of the upcoming features.  This is interesting to me because some of the naysayers stood behind the idea that WebForms was for the enterprise and that ASP.NET MVC is for “small websites”.  All-in-all, you can do enterprise development with either of them.  In my opinion, it’s an architectural decision fraught with many trade-offs, but I digress.

Backwords compatibility

For ASP.NET 2.0, we will be able to use it with Visual Studio 2008 SP1 as well as 2010.  I’m glad this is the case, and until there are some .Net 4.0 features baked in, it will continue to be possible.

What you’ve been waiting for:  the feature list

I’m going to cut to the chase and just quote what Phil Haack posted on the CodePlex ASP.NET site:

  • Areas – Provide a means of grouping controllers and views to build out subsections of a site in isolation.
  • Asynchronous Controller Actions – Provide an asynchronous programming model for controller actions for improved scalability.
  • Strongly-typed input helpers – Expression-based helpers for generating form fields against the model.
  • Strongly-typed link helpers – strongly typed helpers for generating action links
  • Support for Data Annotations – The default model binder will include support for Data Annotations attributes (a la Dynamic Data).
  • Caching Improvements – Improve various caching scenarios.
  • Misc – Various improvements
  • What I’m most excited about

    Areas are very interesting!  Now, the term “areas” has different meaning from this in MonoRail as well as the current implementations out there.  Currently, we can use it to group controllers and views.  If I read this correcting, this implementation will take routes into consideration also.

    Imagine this scenario:  I start a project that needs user logins and a user administration section to create users, reset passwords as well as role-based configuration. . . .with ASP.NET MVC areas, I would be able to take a dependency on, let’s say, MvcContrib.UserManagement.dll, and in my Application_Start() method just call a few lines of start-up code to wire in the routes of the user management pages.  After that, the urls would just be handled by the other assembly.  I’m sure I’d have to implement some interfaces defined therein to hook into my own User object, but the power of this is just tremendous.

    Here is another prediction

    “Areas are the control model (commercial model) for ASP.NET MVC”.  You heard it here first, folks.  No, actually you didn’t.  The masterminds are on Phil’s team.  If the team gets nothing else, I sure hope areas stay at the top of that list.  This is going to be a very exciting release!

    We can’t say thank you enough

    Phil, and the ASP.NET MVC team had an extremely open and transparent 1.0 release cycle with half a dozen public CTPs released.  They got loads of feedback, and sometimes it’s a bit negative.  Then again, if nobody cared about the product, no one would say anything. 

    This product is doing so much to streamline the development of my company, Headspring Systems.  We were headed down a course of MonoRail adoption (and we have that in production as well) when ASP.NET MVC came along.  I want to say “thank you” again to:

    • Scott Guthrie for his visionary leadership and initial prototype
    • Phil Haack for his leadership to make the vision a reality
    • Rob Conery, Levi Broderick, Eilon Lipton, and everyone else at Microsoft who made the product a reality
    • Scott Hanselman for marketing the product to the community
    • Brad Wilson for laboring with the idea of Dynamic Data templates with ASP.NET MVC (don’t give up!)

    Rackspace Cloud (MOSSO) doesn’t support Linq2Sql? (ReflectionPermission CAS)

    I tried to set up a website with Mosso, the Rackspace cloud.  What was really interesting and much more compelling that Azure is that they claim they support .Net 3.5 SP1 and ASP.NET MVC as well as SQL Server 2008.  Oh, and they support scheduled cron jobs.  Slam dunk, I thought. 

    I got my account all set up and deployed a plain site on IIS7.  The ASP.NET MVC site worked right away.  I thought I was home free until I actually did something interesting with .Net 3.5 features where so many do a Code Access Security claim for ReflectionPermission.  Bomb!


    The text reads:

    System.Security.SecurityException: Request for the permission of type ‘System.Security.Permissions.ReflectionPermission, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089’ failed.

    It turns out that Mosso uses a modified medium trust level.  In reality, so many of the cool new .Net 3.5 SP1 features (including Linq2Sql) require ReflectionPermission.  It’s just one of those basics that a hosting provider needs to support.

    I would love to support Rackspace and Mosso.  I have other clients at Rackspace, and the product and support are awesome.  I can’t really recommend Mosso right now because of this severe limitation for the .Net platform. 

    Agile Architecture Up Front (ADUF)

    BDUF (Big Design Up Front) has been decried by many agilists, including myself.  With any project, trying to specify lots and lots of interlocking decisions is risky because as soon as one decisions has to be changed, all the other decisions that depend on it must be adjusted as well.  Many folks I have spoken with have been involved with large projects where one or two month in, the initial specification was obsolete and almost useless.

    In this post, I am attempting to address where architecture is defined on an agile project.  I am going to create several broad categories for the purpose of mental digestion.  This is not an exhaustive analysis.  Rather, it is a thread of my experience.  In this post, I’m not addressing class design or method design.  I’m addressing broad software design (architecture) and where its place is on an agile project.  Consider the following broad environments:

    • Teams of 3-5 developers, shared analyst/customer
    • Teams of 8-25 developers, dedicated analysts
    • Teams larger than that

    Before I break them down and address each individually, I have to divulge that I have never worked on a software project that could be considered “large”, i.e., over 200 people.  For those projects, I’m sure there are plenty of patterns, but my experience is not in that space.

    2-5 developers, shared analyst/customer

    In this type of environment, you may have a dedicated architect, but it is likely that you don’t.  The types of systems that this small of the team can build and maintain are limited; therefore, the architecture might be something the senior developers can tackle.  There is a lot of wiggle room in this space given the context.  If all of the developers are junior, then you need an architect who can make some high level design decisions so that you don’t end up with ad-hoc software.  Most likely there is a senior member of the team who can perform architecture work during normal development cycles.  It is likely that there is no pain created by doing just-in-time architecture

    8-25 developers, dedicated analysts

    As the projects get larger, the number of communication conduits between the developers increases to a point where communication is a burden.  It becomes harder and harder to get all of them around a whiteboard and perform just-in-time architecture.  In this environment, it often, not always, becomes necessary to define some level of architecture up front.  When I use the term “up front”, I am referring to some time before a developer attempts to put the functionality in code form.  With the way Headspring works, this is anywhere from 1 hour to 100 hours before a developer pair looks at what is needed to be done.  The development team gets a head start on the iteration because instead of beginning by parsing requirements, they are given specifications which have been created recently in the context of the larger system.  With the smaller team, the specifications happen on the fly, and they are often conversations or simple whiteboard drawings.  In the slightly larger teams, the architecture has to be communication to more people, so architecture artifacts and diagrams are necessary.  Software specifications start to become necessary.

    Teams larger than that

    I won’t speak to software projects with hundreds of developers on the same system because that is not where my experience lies.  I will address, however, the forces I know are in play as the team grows larger and larger.  The number of communication conduits increases exponentially.  With 50 developers, you have so many paths of communication that you start to split the team up into sub teams.  Architecture is so much more important because designing and communicating the architecture is so important to keeping the software consistent.  Because the architecture needs to be communicated more broadly, it has to be defined earlier in the process.  This is more architecture up front (ADUF). 

    Overall Idea

    Every system has an architecture.  The tool of the .Net platform, Visual Studio, provides a default architecture, which is 2-tier, single layered.  If you don’t like that architecture, then you are on your own to adopt or define an alternative.  If you are using an alternative, when does that get defined in an agile project, and how much is defined when?

    Architecture happens.  Smaller teams mix it in everywhere.  Larger teams have a larger coordination overhead, so it has to be defined in a more structured environment.  The “when” and the “how much” fluctuate with the situation, but architecture is always there. 

    In the reaction against BDUF, I have seen the full pendulum swing to the other extreme of NDUG (No Design Up Front).  Many have witnesses this as well and have called for “just enough design up front”. 

    The lesson I am trying to share here is that when communication and coordination become a challenge, more architecture has to be defined in a structured manner before the larger body of programmers start whipping out code.   When Agile principles are applied to a software development project, software is delivered in small, incremental pieces.  With these repetitive cycles, the project is naturally broken up into a rhythm of delivery.  With each cycle, the requirements need to flow into specifications that need to flow into working software.  In small teams, that process can be fluid and ad-hoc, often verbal.  As the number of developers increased, it creates the need for more structure around communicating architectural decisions.  This communication need creates the need to do more architecture ahead of each iteration. 

    Practical Experience

    A process I have seen work quite well when a project with 8-25 developers has a dedicated architect (or architecture team) that works ahead of a development iteration.  They process the roadmap (requirements) and create specifications at a detailed-enough level that the development team can estimate the work.  Then, the specifications are consumed by the development team.  At the other end is software.

    Consistency makes a difference, and 87.9% difference

    I was recently comparing two systems.  Here are the commonalities of the systems:

    • .Net 3.5
    • ASP.NET
    • C#
    • SQL Server 2005
    • 2 tiers, multi-layered

    Here are the stats for System A

    • 227 distinct screens (pages)
    • 176,510 lines of code

    Here are the stats for System B

    • 234 distinct screens
    • 23,724 lines of code

    Size difference? 87.9%

    These are both line-of-business applications.  Why such the big difference in lines of code?

    Answer:  consistency & architecture

    Both systems are very successful and meet the needs of the business, so it’s not a matter of bad/good.


    I don’t have time to do a full analysis of the causal relationship (I don’t know what that would be), but this is very interesting to me.  Increased lines of code means increased Total Cost of Ownership.  I have an incentive to deliver functionality using the least amount of code.  I don’t get this by combining lines of code but by applying architectural principles to eliminate code duplication and increase reuse.

    Credit:  Thanks to Eric Hexter for pulling these numbers.

    ASP.NET MVC and the templated partial view (death to ASCX)

    Subscribe to my feed here:

    We are used to master pages and applying them to ASPX pages.  Then we pull small parts of the view into user controls or ASCX.  In ASP.NET MVC, we use ASCX files as partial views because the user control model is so baked into our thinking.

    I propose that ASCX does not provide much benefit in ASP.NET MVC.  It’s usefulness may end with using the extension as a naming convention for the easy identification of partial views.  Beyond that, it’s pretty thin.

    Consider the following scenario where only the ASPX extension is used for views and partial views.  The partial views, because they are ASPX files, are able to leverage master pages for small-scale templating.  Using master pages for nested templates around partials gives us a whole new dynamic with which to break down web pages in ASP.NET MVC.


    The above screen shot is the screen we are going for.  We want consistent formatting for two partials that would hold charts.  Here is a code sample based on the basic project template.  I have enhanced the Home Index.aspx view as follows:


    <%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" 
    Inherits="System.Web.Mvc.ViewPage" %>

    <asp:Content ID="indexTitle" ContentPlaceHolderID="TitleContent" runat="server">
    Home Page

    <asp:Content ID="indexContent" ContentPlaceHolderID="MainContent" runat="server">
    <h2><%= Html.Encode(ViewData["Message"]) %></h2>
    "float:left">"chart1"); %>

    "float:left">"chart2"); %>


    To learn more about ASP.NET MVC visit <a href=""
    title="ASP.NET MVC Website"></a>.

    You see we are rendering two partials, chart1 and chart2.  Here is the code for the partials:


    <%@ Page Language="C#" MasterPageFile="~/Views/Shared/ChartLayout.Master" 
    Inherits="System.Web.Mvc.ViewPage" %>

    <asp:Content ContentPlaceHolderID="Main" runat="server">
    Chart 1 goes here


    <%@ Page Language="C#" MasterPageFile="~/Views/Shared/ChartLayout.Master" 
    Inherits="System.Web.Mvc.ViewPage" %>

    <asp:Content ContentPlaceHolderID="Main" runat="server">
    Chart 2 goes here

    Notice that each of these partials declare a master page.  Let’s see what templating the master page gives us:


    <%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>
    "border:solid 4px green;padding:100px;margin:20px">
    "Main" runat="server">

    The css styling is what to look for.  Each partial is surrounded by a green border with padding and margin.  This formatting is consistently applied by the master page declared in both the partials.  The main view doesn’t care about this partial formatting because it belongs to the partial.  Look again to the screenshot above.  Because we used ASPX partial views, we gained the formatting capability of master pages.