When you're using Windows Authentication, perhaps for an intranet application hosted in a Windows domain, it's often reasonable to require authentication for all requests. That way, visitors are always logged in, and User.Identity.Name will always be populated with the visitor's domain account name. To enforce this, be sure to configure IIS to disable anonymous access (Figure 17-2).

However, if you want to allow unauthenticated access to certain application features (such as your site's homepage) but enforce Windows Authentication for other application features (such as administrative pages), then you need to configure IIS to allow both anonymous access and one or more other authentication options (Figure 17-2). In this arrangement, anonymous access is considered to be the default. Authentication is triggered by any of the following scenarios:

The last two options are the most useful ones in an ASP.NET MVC application, because they give you complete control over which controllers and actions allow anonymous access and which require authentication.

When you create a blank new ASP.NET MVC 2 application, the default project template enables Forms Authentication for you by default. The default Web.config file includes the following:

<authentication mode="Forms">
    <forms loginUrl="~/Account/LogOn" timeout="2880"/>
</authentication>

This simple configuration is good enough to get you started. If you want more control over how Forms Authentication works, check out the options listed in Table 17-2, which can all be applied to your Web.config file's <forms> node.

There are other configuration options, but these are the ones you're most likely to use.

As an alternative to editing the <forms> configuration node by hand, you can also use IIS 7.x's Authentication configuration tool, which edits Web.config on your behalf. To do this, open the Authentication tool, and then right-click and enable Forms Authentication. Next, right-click Forms Authentication and choose Edit to configure its settings (see Figure 17-3).

Figure 17-3. IIS 7's Authentication configuration tool when editing Forms Authentication settings

With Forms Authentication enabled in your Web.config file, when an unauthenticated visitor tries to access any controller or action marked with [Authorize] (or any action that returns an HttpUnauthorizedResult), they'll be redirected to your login URL.

The Forms Authentication system supports a rarely used cookieless mode, in which authentication tickets are preserved by stashing them into URLs. As long as each link on your site contains the visitor's authentication ticket, then the visitor will have the same logged-in experience without their browser needing to permit or even support cookies.

Why wouldn't someone permit cookies? These days, most people will. It's understood that a lot of web applications don't function correctly if you don't allow cookies, so, for example, most web mail services will just kick such visitors out, saying, "Sorry, this service requires cookies." Nonetheless, if your situation demands it, perhaps because visitors use older mobile devices that won't allow cookies, you can switch to cookieless mode in your Web.config file, as follows:

<authentication mode="Forms">
  <forms loginUrl="~/Account/LogOn" timeout="2880" cookieless="UseUri">
  </forms>
</authentication>

Once a visitor logs in, they'll be redirected to a URL like this:

/(F(nMD9DiT464AxL7nlQITYUTT05ECNIJ1EGwN4CaAKKze-9ZJq1QTOK0vhXTx0fWRjAJdgSYojOYyhDil
HN4SRb4fgGVcn_fnZU0x55I3_Jes1))/Home/ShowPrivateInformation

Look closely, and you'll see it follows the pattern /(F(authenticationData))/normalUrl. The authentication data replaces (but is not the same as) what would otherwise have been persisted in the .ASPXAUTH cookie. Of course, this won't match your routing configuration, but don't worry—the platform will rewrite incoming URLs to extract and remove the authentication information before the routing system gets to see those URLs. Plus, as long as you only ever generate outbound URLs using the MVC Framework's built-in helpers (such as Html.ActionLink()), the authentication data will automatically be prepended to each URL generated. In other words, it just works.

The framework comes with membership providers for SQL Server (SqlMembershipProvider) and Active Directory (ActiveDirectoryMembershipProvider). These two are the most commonly used, so they are the ones you'll learn about in this chapter. Many other prebuilt membership providers are just a web search away, including ones based around Oracle, NHibernate, and XML files.

Setting Up SqlMembershipProvider

When you create a new ASP.NET MVC 2 application (except when using the Empty project template), it's configured to use SqlMembershipProvider by default. Your Web.config file will initially include the following entries:

<configuration>
  <connectionStrings>
    <add name="ApplicationServices"
         connectionString="data source=.SQLEXPRESS;Integrated Security=SSPI;
                           AttachDBFilename=|DataDirectory|aspnetdb.mdf;
                           User Instance=true"
         providerName="System.Data.SqlClient" />
  </connectionStrings>
  <system.web>
    <membership>
        <providers>
            <clear/>
            <add name="AspNetSqlMembershipProvider"
                 type="System.Web.Security.SqlMembershipProvider"
                 connectionStringName="ApplicationServices"
                 ... />
        </providers>
    </membership>
  </system.web>
</configuration>

Note

If you use the ASP.NET MVC 2 Empty Web Application project template, it doesn't prepopulate any connection strings or membership providers in Web.config (it's supposed to be empty, of course). So, to use SqlMembershipProvider, you'll need to add configuration along the lines shown here, or copy it from a nonempty ASP.NET MVC 2 application.

Using a SQL Server Express User Instance Database

SQL Server 2005 Express Edition and SQL Server 2008 Express Edition both support user instance databases. Unlike regular SQL Server databases, these databases don't have to be created and registered in advance. You simply open a connection to SQL Server Express saying where the database's .mdf file is stored on disk. SQL Server Express will open the .mdf file, creating it on the fly first if needed. This can be convenient in simple web hosting scenarios because, for instance, you don't even have to configure SQL logins or users.

Notice how this is configured in the preceding Web.config settings. The default connection string specifies User Instance=true. The special AttachDBFilename syntax tells the system to create a SQL Server Express user instance database at ~/App_Data/aspnetdb.mdf. When ASP.NET first creates the database, it will prepopulate it with all the tables and stored procedures needed to support the Membership, Roles, and Profiles features.

If you plan to store your data in SQL Server Express edition—and not in any other edition of SQL Server—then you can leave these settings as they are. However, if you intend to use a non-Express edition of SQL Server, you must create your own database and prepare its schema manually, as I'll describe next.

Note

These default settings assume you have an Express edition of SQL Server installed locally. If you don't, any attempt to use SqlMembershipProvider will result in an error saying, "SQLExpress database file autocreation error." You must either install SQL Server Express locally, change the connection string to refer to a different server where SQL Server Express is installed, or change the connection string to refer to a database that you've already prepared manually.

Preparing Your Own Database for Membership, Roles, and Profiles

If you want to use a non-Express edition of SQL Server (i.e., any of the for-pay editions), then you'll need to create your own database in the usual way through SQL Server Management Studio or Visual Studio. To add the schema elements required by SqlMembershipProvider, run the tool aspnet_regsql.exe (without specifying any command-line arguments), which is in your .NET Framework directory.^[114] This tool includes the screen shown in Figure 17-5.

Figure 17-5. Initializing your database schema for SqlMembershipProvider

Once you've told it how to find your database, it adds a set of tables and stored procedures that support the Membership, Roles, and Profiles features, all prefixed by aspnet_ (Figure 17-6). You should then set your connection string in Web.config to refer to your manually created database.

Figure 17-6. Tables and stored procedures added to support SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider

Managing Members Using the Web Administration Tool

Visual Studio ships with a tool called the Web Administration Tool (WAT). It's a GUI for managing your site's settings, including your Membership, Roles, and Profiles data. Launch it from Visual Studio by selecting the menu item Project

Figure 17-7. The WAT

Internally, the WAT uses the Membership APIs to talk to your default membership provider, so the WAT is compatible with any MembershipProvider, including any custom one you might create.

When you finally deploy your application to a production web server, you'll find that the WAT isn't available there. That's because the WAT is part of Visual Studio, which you're unlikely to have installed on the web server. It is technically possible to deploy the WAT to your web server (see http://forums.asp.net/p/1010863/1761029.aspx), but it's tricky, so in reality you're more likely to develop your own UI using the Membership APIs. Or, if you're running IIS 7.x, you can use its .NET Users configuration tool.

Managing Members Using IIS 7.x's .NET Users Configuration Tool

Among IIS 7.x Manager's many brightly colored icons, you'll find .NET Users (Figure 17-8).

Figure 17-8. IIS 7's .NET Users GUI

As well as allowing you to create, edit, and delete members, this tool also lets you configure a default membership provider. Just like the WAT, it edits your application's root Web.config file on your behalf, and it uses the Membership APIs to communicate with your registered MembershipProvider.

Unlike the WAT, the .NET Users tool will be available on your production server (assuming it runs IIS 7.x). It's therefore a very quick way to get basic member management functionality for small applications where membership is managed only by your server administrator.

Warning

At the time of writing, IIS 7.x Manager's .NET Users tool doesn't work with the default membership providers for .NET 4 applications—it fails, saying, "This feature cannot be used because the default provider type could not be determined to check whether it is a trusted provider." For information about this bug, see http://tinyurl.com/y6vrtqv. As that web page explains, the current workaround involves manually editing Web.config to use the .NET 3.5 version of SqlMembershipProvider.

It's likely that you'll want to use your membership provider to validate login attempts. This is very easy! For example, to upgrade SportsStore to work with your membership provider, just change one line of code in AccountController's LogOn() method as follows:

[HttpPost]
public ActionResult LogOn(LogOnViewModel model, string returnUrl)
{
   if (ModelState.IsValid) // No point trying authentication if model is invalid
      if (!Membership.ValidateUser(model.UserName, model.Password))
         ModelState.AddModelError("", "Incorrect username or password");

   ... rest as before ...
}

Previously, this method validated login attempts by calling FormsAuthentication.Authenticate(username, password), which looks for credentials in a <credentials> node in Web.config. Now, however, it will only accept login attempts that match valid credentials known to your active membership provider.

In many cases, you might decide that ASP.NET's built-in membership providers aren't appropriate for your application. ActiveDirectoryMembershipProvider is only applicable in certain corporate domain scenarios, and SqlMembershipProvider uses its own custom SQL database schema, which you might not want to mix with your own schema.

You can create a custom membership provider by deriving a class from MembershipProvider. Start by writing the following:

public class MyNewMembershipProvider : MembershipProvider
{
}

and then right-click MembershipProvider and choose Implement Abstract Class. You'll find there are quite a lot of methods and properties—currently all throwing a NotImplementedException—but you can leave most of them as they are. To integrate with Forms Authentication, the only method that you strictly need to attend to is ValidateUser(). Here's a very simple example:

public class SiteMember
{
    public string UserName { get; set; }
    public string Password { get; set; }
}

public class SimpleMembershipProvider : MembershipProvider
{
    // For simplicity, just working with a static in-memory collection
    // In any real app you'd need to fetch credentials from a database
    private static List<SiteMember> Members = new List<SiteMember> {
        new SiteMember { UserName = "MyUser", Password = "MyPass" }
    };

    public override bool ValidateUser(string username, string password)
    {
        return Members.Exists(m => (m.UserName==username)&&(m.Password==password));
    }

    /* Omitted: All the other methods just throw NotImplementedException */
}

Once you've created your custom membership provider, register it in your Web.config file as follows:

<configuration>
  <system.web>
    <membership defaultProvider="MyMembershipProvider">
      <providers>
        <clear/>
        <add name="MyMembershipProvider"
             type="Namespace.SimpleMembershipProvider"/>
      </providers>
    </membership>

</system.web>
</configuration>

If you want your custom membership provider to support adding and removing members, integrating with the WAT and IIS 7.x's .NET Users GUI, then you'll need to add behavior to other overridden methods such as CreateUser() and GetAllUsers().

So far, you've seen how the framework manages your application's set of credentials and validates login attempts (via a membership provider), and how it keeps track of a visitor's logged-in status across multiple requests (via Forms Authentication). Both of these are matters of authentication, which means securely identifying who a certain person is.

The next common security requirement is authorization, which means deciding what a certain person is allowed to do. The framework offers a system of role-based authorization, by which each member can be assigned to a set of roles, and their membership of a given role is understood to denote authorization to perform certain actions. A role is merely a unique string, and it only has meaning in that you choose to associate meanings with certain strings. For example, you might choose to define three roles:

These are just arbitrary strings, but they gain meaning when, for example, your application grants administrator console access only to members in the SiteAdministrator role.

Each role is totally independent of the others—there's no hierarchy—so being a SiteAdministrator doesn't automatically grant the CommentsModerator role or even the ApprovedMember role. Each one must be assigned independently; a given member can hold any combination of roles.

Just as with membership, the ASP.NET platform expects you to work with roles through its provider model, offering a common API (the RoleProvider base class) and a set of built-in providers you can choose from. And of course, you can implement your own custom provider.

Also as with membership, you can manage roles (and grant or deny roles to members) using either the WAT or IIS 7.x's .NET Roles and .NET Users configuration tools, as shown in Figure 17-9.

Figure 17-9. Using IIS 7's .NET Users tool to edit a user's roles

In most cases—and not just because of the incompatibility with .NET 4—it will be more useful not to use the built-in tools, and instead create your own custom administration screens within your application. You can manage roles using the static System.Web.Security.Roles object, which represents your default membership provider. For example, you can use the following to add a user to a role:

Roles.AddUserToRole("billg", "CommentsModerator");

<configuration>
  <system.web>
    <roleManager enabled="false">

<providers>
        <clear/>
        <add name="AspNetSqlRoleProvider"
             type="System.Web.Security.SqlRoleProvider"
             connectionStringName="ApplicationServices"
             applicationName="/" />
        <add name="AspNetWindowsTokenRoleProvider"
             type="System.Web.Security.WindowsTokenRoleProvider"
             applicationName="/" />
      </providers>
    </roleManager>
  </system.web>
</configuration>

<roleManager enabled="true" defaultProvider="AspNetSqlRoleProvider">

[Authorize(Roles="CommentsModerator, SiteAdministrator")]
public ViewResult ApproveComment(int commentId) {
    // Implement me
}

public class MyRoleProvider : RoleProvider

{
    public override string[] GetRolesForUser(string username)
    {
        // Your real provider should probably fetch roles info from a database
        if (username == "Steve")
            return new string[] { "ApprovedMember", "CommentsModerator" };
        else
            return new string[] { };
    }

    /* Omitted: Everything else throws a NotImplementedException */
}

Membership keeps track of your members, and Roles keeps track of what they're allowed to do. But what if you want to keep track of other per-user data like "member points" or "site preferences" or "favorite foods"? That's where Profiles comes in: it's a general purpose, user-specific data store that follows the platform's familiar provider pattern.

It's an appealing option for smaller applications that are built around SqlMembershipProvider and SqlRoleProvider, because it uses the same database schema, so it feels like you're getting something for nothing. In larger applications, though, where you have a custom database schema and a stronger notion of a domain model, you will probably have different, better infrastructure for storing per-user data specific to your application, so you would not really benefit from using Profiles.

<configuration>
  <system.web>
    <profile>
      <providers>
        <clear/>
        <add name="AspNetSqlProfileProvider"
             type="System.Web.Profile.SqlProfileProvider"
             connectionStringName="ApplicationServices"
             applicationName="/" />
      </providers>
    </profile>
  </system.web>
</configuration>

<profile>
  <providers>...</providers>
  <properties>
    <add name="Name" type="String" />
    <add name="PointsScored" type="Integer" />
    <group name="Address">
      <add name="Street" type="String" />
      <add name="City" type="String" />
      <add name="ZipCode" type="String" />
      <add name="State" type="String" />
      <add name="Country" type="String" />
    </group>
  </properties>
</profile>

public ActionResult ShowMemberNameAndCountry ()
{
    ViewData["memberName"] = HttpContext.Profile["Name"];
    ViewData["memberCountry"]
        = HttpContext.Profile.GetProfileGroup("Address")["Country"];
    return View();
}

public RedirectToRouteResult SetMemberNameAndCountry(string name, string country)
{
    HttpContext.Profile["Name"] = name;
    HttpContext.Profile.GetProfileGroup("Address")["Country"] = country;
    return RedirectToAction("ShowMemberNameAndCountry");
}

<profile>
  <properties>
    <add name="Name" type="String" allowAnonymous="true" />
  </properties>
</profile>

<configuration>
    <system.web>
        <anonymousIdentification enabled="true" />
    </system.web>
</configuration>

public class InMemoryProfileProvider : ProfileProvider
{
    // This is an in-memory collection that never gets persisted to disk
    // Warning: For brevity, no attempt is made to keep this thread safe
    // The keys in this dictionary are user names; the values are
    // dictionaries of profile data for that user
    private static IDictionary<string, IDictionary<string, object>> _data
        = new Dictionary<string, IDictionary<string, object>>();

    public override SettingsPropertyValueCollection GetPropertyValues(
            SettingsContext context, SettingsPropertyCollection collection)
    {
        // See if we've got a record of that user's profile data
        IDictionary<string, object> userData;
        _data.TryGetValue((string)context["UserName"], out userData);

        // Now build and return a SettingsPropertyValueCollection
        var result = new SettingsPropertyValueCollection();
        foreach (SettingsProperty prop in collection)
        {
            var spv = new SettingsPropertyValue(prop);
            if (userData != null) // Use user's profile data if available
                spv.PropertyValue = userData[prop.Name];
            result.Add(spv);
        }
        return result;
    }

    public override void SetPropertyValues(SettingsContext context,
                            SettingsPropertyValueCollection collection)
    {
        string userName = (string)context["UserName"];
        if (string.IsNullOrEmpty(userName))
            return;

        // Simply converts SettingsPropertyValueCollection to a dictionary
        _data[userName] = collection.Cast<SettingsPropertyValue>()
                                   .ToDictionary(x => x.Name, x => x.PropertyValue);
    }

    /* Omitted: Everything else throws NotImplementedException */
}

Because it's such a common requirement, ASP.NET has a special API for configuring connection strings. If you add entries to your Web.config file's <connectionStrings> node, such as the following:

<configuration>
  <connectionStrings>
    <add name="MainDB" connectionString="Server=myServer;Database=someDB; ..."/>
    <add name="AuditingDB" connectionString="Server=audit01;Database=myDB; ..."/>
  </connectionStrings>
</configuration>

then you can access those values via WebConfigurationManager.ConnectionStrings—for example:

string connectionString = WebConfigurationManager.ConnectionStrings["MainDB"];

If you need a simple way to configure anything other than connection strings, you can use the Web.config file's <appSettings> node, which accepts arbitrary key/value pairs—for example:

<configuration>
  <appSettings>
    <add key="Mailer.ServerHost" value="smtp.example.com"/>
    <add key="Mailer.ServerPort" value="25"/>
    <add key="Uploader.TempDirectory" value="e:webdatauploadedFiles"/>
  </appSettings>
</configuration>

Then you can access those values using WebConfigurationManager.AppSettings as follows:

string host = WebConfigurationManager.AppSettings["Mailer.ServerHost"];
int port = int.Parse(WebConfigurationManager.AppSettings["Mailer.ServerPort"]);

Sometimes you'll want to configure data structures that are more complex than simple key/value pairs. For example, you might want to configure an ordered list or a hierarchy of settings, which would be difficult to express as entries in a key/value collection.

To configure an arbitrary list or hierarchy of structured settings, start simply by representing those settings as free-form XML in your Web.config file's <configuration> node—for example:

<configuration>
  <mailServers>
    <server host="smtp1.example.com" portNumber="25">
      <useFor domain="example.com"/>
      <useFor domain="staff.example.com"/>
      <useFor domain="alternative.example"/>
    </server>
    <server host="smtp2.example.com" portNumber="5870">
      <useFor domain="*"/>
    </server>
  </mailServers>
</configuration>

Note that ASP.NET has no native concept of a <mailServers> node—this is just arbitrary XML of my choice. Next, create an IConfigurationSectionHandler class that can understand this XML. You just need to implement a Create() method that receives the custom data as an XmlNode called section, and transforms it into a strongly typed result. This example produces a list of MailServerEntry objects:

public class MailServerEntry
{
    public string Hostname { get; set; }
    public int PortNumber { get; set; }
    public List<string> ForDomains { get; set; }
}

public class MailServerConfigHandler : IConfigurationSectionHandler
{
    public object Create(object parent, object configContext, XmlNode section)
    {
        return section.SelectNodes("server").Cast<XmlNode>()
              .Select(x => new MailServerEntry
              {
                  Hostname = x.Attributes["host"].InnerText,
                  PortNumber = int.Parse(x.Attributes["portNumber"].InnerText),
                  ForDomains = x.SelectNodes("useFor")
                                .Cast<XmlNode>()
                                .Select(y => y.Attributes["domain"].InnerText)
                                .ToList()
              }).ToList();
    }
}

Finally, register your custom configuration section and its IConfigurationSectionHandler class by adding a new node to your Web.config file's <configSections> node:

<configuration>
  <configSections>
    <section name="mailServers" type="namespace.MailServerConfigHandler, assembly"/>
  </configSections>
</configuration>

Then you can access your configuration data anywhere in your code using WebConfigurationManager.GetSection():

IList<MailServerEntry> servers = WebConfigurationManager.GetSection("mailServers")
                                 as IList<MailServerEntry>;

One of the nice things about WebConfigurationManager.GetSection() is that, internally, it caches the result of your IConfigurationSectionHandler's Create() method call, so it doesn't repeat the XML parsing every time a request needs to access that particular configuration section. The cached value expires only when your application is recycled (e.g., after you edit and save your Web.config file).

The simplest usage of Cache is as a name/value dictionary: assign a value to HttpContext.Cache[key], and then read it back from HttpContext.Cache[key]. The data is persisted and shared across all requests, being automatically removed when memory pressure reaches a certain level or after the data remains unused for a sufficiently long period.

You can put any .NET object into Cache—it doesn't even have to be serializable, because the framework holds it in memory as a live object. Items in the Cache won't be garbage-collected, because the Cache holds a reference to them. Of course, that also means that the entire object graph reachable from a cached object can't be garbage-collected either, so be careful not to cache more than you had in mind.

Rather than simply assigning a value to HttpContext.Cache[key], it's better to use the HttpContext.Cache.Add() method, which lets you configure the storage parameters listed in Table 17-3.

As I mentioned earlier, Cache is often used to cache the results of expensive method calls, such as certain database queries or web service calls. The drawback is of course that your cached data may become stale, which means that it might not reflect the most up-to-date results. It's up to you to make the appropriate trade-off when deciding what to cache and for how long.

For example, imagine that your web application occasionally makes HTTP requests to other web servers. It might do this to consume a REST web service, to retrieve RSS feeds, or simply to find out what logo Google is displaying today. Each such HTTP request to a third-party server might take several seconds to complete, during which time you'll be keeping your site visitor waiting for their response. Because this operation is so expensive—even if you run it as a background task using an asynchronous controller—it makes sense to cache its results.

You might choose to encapsulate this logic into a class called CachedWebRequestService, implemented as follows:

public class CachedWebRequestService
{
    private Cache cache; // The reasons for storing this will become apparent later
    private const string cacheKeyPrefix = "__cachedWebRequestService";
    public CachedWebRequestService(Cache cache)
    {

this.cache = cache;
    }

    public string GetWebPage(string url)
    {
        string key = cacheKeyPrefix + url; // Compute a cache key
        string html = (string)cache[key];  // Try retrieving the value
        if (html == null) // Check if it's not in the cache
        {
            // Reconstruct the value by performing an actual HTTP request
            html = new WebClient().DownloadString(url);

            // Cache it
            cache.Insert(key, html, null, DateTime.MaxValue,
                TimeSpan.FromMinutes(15), CacheItemPriority.Normal, null);
        }
        return html; // Return the value retrieved or reconstructed
    }
}

You can invoke this service from an action method by supplying HttpContext.Cache as a constructor parameter:

public string Index()
{
    var cwrs = new CachedWebRequestService(HttpContext.Cache);
    string httpResponse = cwrs.GetWebPage("http://www.example.com");
    return string.Format("The example.com homepage is {0} characters long.",
                         httpResponse.Length);
}

There are two main points to note:

What you've already seen is likely to be sufficient for most applications, but the framework offers a number of extra capabilities to do with dependencies:

Finally, you can specify a callback function to be invoked when a given cache entry expires—for example, to implement a custom cache item dependency system. Another reason to take action on expiration is if you want to recreate the expiring item on the fly. You might do this if it takes a while to recreate the item and you really don't want your next visitor to have to wait for it. Watch out, though; you're effectively setting up an infinite loop, so don't do this with a short expiration timeout.

Here's how to modify the preceding example to repopulate each cache entry as it expires:

public string GetWebPage(string url)
{
    string key = cacheKeyPrefix + url; // Compute a cache key
    string html = (string)cache[key];  // Try retrieving the value
    if (html == null) // Check if it's not in the cache
    {
        // Reconstruct the value by performing an actual HTTP request
        html = new WebClient().DownloadString(url);

        // Cache it
        cache.Insert(key, html, null, DateTime.MaxValue,
            TimeSpan.FromMinutes(15), CacheItemPriority.Normal, OnItemRemoved);
    }
    return html; // Return the value retrieved or reconstructed
}

void OnItemRemoved(string key, object value, CacheItemRemovedReason reason)
{
    if (reason == CacheItemRemovedReason.Expired)
    {
        // Repopulate the cache
        GetWebPage(key.Substring(cacheKeyPrefix.Length));
    }
}

Note that the callback function gets called outside the context of any HTTP request. That means you can't access any Request or Response objects (there aren't any—not even via System.Web.HttpContext.Current), nor can you produce any output visible to any visitor. The only reason the preceding code can still access Cache is because it keeps its own reference to it.

To get started using the default XmlSiteMapProvider, right-click the root of your project and choose Add

<siteMap defaultProvider="MyXmlSiteMapProvider" enabled="true">
   <providers>
     <add name="MyXmlSiteMapProvider" type="System.Web.XmlSiteMapProvider"
       siteMapFile="~/Folder/MySiteMapFile.sitemap" />
   </providers>
 </siteMap>

You can now fill in Web.sitemap, describing your site's navigation structure using the standard site map XML schema—for example:

<?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
  <siteMapNode url="~/ " title="Home"  description="">
    <siteMapNode url="~/Home/About" title="About"  description="All about us"/>
    <siteMapNode url="~/Home/Another" title="Something else"/>
    <siteMapNode url="http://www.example.com/" title="Example.com"/>
  </siteMapNode>
</siteMap>

Next, put the built-in SiteMapPath control in your master page:

<asp:SiteMapPath runat="server"/>

and it will display the visitor's current location in your navigation hierarchy (Figure 17-10).

Figure 17-10. A SiteMapPath control

Breadcrumb navigation is very nice, but you're likely to need some kind of menu too. It's quite easy to build a custom HTML helper that obtains navigation information using the SiteMap class. For example, put the following class anywhere in your application:

public static class SiteMapHelpers
{
    public static void RenderNavMenu(this HtmlHelper html)
    {
        HtmlTextWriter writer = new HtmlTextWriter(html.ViewContext.Writer);
        RenderRecursive(writer, SiteMap.RootNode);
    }

    private static void RenderRecursive(HtmlTextWriter writer, SiteMapNode node)
    {
        if (SiteMap.CurrentNode == node) // Highlight visitor's location
            writer.RenderBeginTag(HtmlTextWriterTag.B); // Render as bold text
        else
        {
            // Render as link
            writer.AddAttribute(HtmlTextWriterAttribute.Href, node.Url);
            writer.RenderBeginTag(HtmlTextWriterTag.A);
        }
        writer.Write(node.Title);
        writer.RenderEndTag();

        // Render children
        if (node.ChildNodes.Count > 0)

{
            writer.RenderBeginTag(HtmlTextWriterTag.Ul);
            foreach (SiteMapNode child in node.ChildNodes)
            {
                writer.RenderBeginTag(HtmlTextWriterTag.Li);
                RenderRecursive(writer, child);
                writer.RenderEndTag();
            }
            writer.RenderEndTag();
        }
    }
}

RenderNavMenu() is an extension method, so you'll only be able to use it in a particular master page or view after importing its namespace. So, add the following at the top of your master page or view:

<%@ Import Namespace="insert namespace containing SiteMapHelpers" %>

Now you can invoke the custom HTML helper as follows:

<% Html.RenderNavMenu(); %>

Depending on your site map configuration and the visitor's current location, this will render something like the following:

<a href="/">Home</a>
<ul>
    <li><b>About</b></li>
    <li><a href="/Home/Another">Something else</a></li>
    <li><a href="http://www.example.com/">Example.com</a></li>
</ul>

Of course, you can add any formatting, CSS, or client-side scripting of your choosing.

ASP.NET's default site map provider, XmlSiteMapProvider, expects you to specify an explicit URL for each site map node. XmlSiteMapProvider predates the routing system.

But in your ASP.NET MVC application, wouldn't it be better not to specify explicit URLs, and instead generate the URLs dynamically according to your routing configuration? Perhaps you'd like to replace your Web.sitemap contents with the following:

<?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
  <siteMapNode title="Home" controller="Home" action="Index">
    <siteMapNode title="About" controller="Home" action="About"/>
    <siteMapNode title="Log in" controller="Account" action="LogOn"/>
  </siteMapNode>
</siteMap>

Notice that there are no URLs hard-coded into this configuration. This configuration won't work with the default XmlSiteMapProvider, but you can make it work by creating a custom site map provider. Add the following class anywhere in your project:

public class RoutingSiteMapProvider : StaticSiteMapProvider
{
    private SiteMapNode rootNode;

    public override void Initialize(string name, NameValueCollection attributes)
    {
        base.Initialize(name, attributes);

        // Load XML file, taking name from Web.config or use Web.sitemap as default
        var xmlDoc = new XmlDocument();
        var siteMapFile = attributes["siteMapFile"] ?? "~/Web.sitemap";
        xmlDoc.Load(HostingEnvironment.MapPath(siteMapFile));
        var rootSiteMapNode = xmlDoc.DocumentElement["siteMapNode"];

        // Build the navigation structure
        var httpContext = new HttpContextWrapper(HttpContext.Current);
        var requestContext = new RequestContext(httpContext, new RouteData());
        rootNode = AddNodeRecursive(rootSiteMapNode, null, requestContext);
    }

    private static string[] reservedNames = new[] {"title","description","roles"};
    private SiteMapNode AddNodeRecursive(XmlNode xmlNode, SiteMapNode parent,
                                         RequestContext context)
    {
        // Generate this node's URL by querying RouteTable.Routes
        var routeValues = (from XmlNode attrib in xmlNode.Attributes
                           where !reservedNames.Contains(attrib.Name.ToLower())
                           select new { attrib.Name, attrib.Value })
                          .ToDictionary(x => x.Name, x => (object)x.Value);
        var routeDict = new RouteValueDictionary(routeValues);
        var url = RouteTable.Routes.GetVirtualPath(context, routeDict).VirtualPath;

        // Register this node and its children
        var title = xmlNode.Attributes["title"].Value;
        var node = new SiteMapNode(this, Guid.NewGuid().ToString(), url, title);
        base.AddNode(node, parent);
        foreach (XmlNode childNode in xmlNode.ChildNodes)
            AddNodeRecursive(childNode, node, context);
        return node;
    }

    // These methods are called by ASP.NET to fetch your site map data
    protected override SiteMapNode GetRootNodeCore() { return rootNode; }
    public override SiteMapNode BuildSiteMap() { return rootNode; }
}

Enable your custom site map provider by adding the following inside Web.config's <system.web> node:

<siteMap defaultProvider="MyProvider">
  <providers>
    <clear/>
    <add name="MyProvider" type="Namespace.RoutingSiteMapProvider"/>
  </providers>
</siteMap>

This took a bit more work than just using ASP.NET's built-in site map provider, but I think it was worth it. You can now define site map entries in terms of arbitrary routing data without hard-coding any URLs. Whenever your routing configuration changes, so will your navigation UI. You're not limited to specifying only controller and action in your site map file—you can specify any custom routing parameters, and the appropriate URLs will be generated according to your routing configuration.

<siteMap defaultProvider="MyProvider">
  <providers>
    <clear/>
    <add name="MyProvider" type="Namespace.RoutingSiteMapProvider"
         securityTrimmingEnabled="true"/>
  </providers>
</siteMap>

public class RoutingSiteMapProvider : StaticSiteMapProvider
{
    // Rest of class as before

    public override bool IsAccessibleToUser(HttpContext context, SiteMapNode node)
    {
        if(node == rootNode) return true; // Root node must always be accessible

        // Insert your custom logic here
    }
}

It's very easy to get started with localizing text in your MVC application. Right-click your project in Solution Explorer and choose Add

Figure 17-11. A resource file for the application's default culture

The values given here (in Resources.resx) will be the application's defaults. You will of course want to support another language, so create a similar resource file with the same name, except with the designation of a culture inserted into the middle (e.g., Resources.en-GB.resx or Resources.fr-FR.resx). Figure 17-12 shows my Resources.en-GB.resx file.

Figure 17-12. The resource file for the en-GB culture

Now, when you first saved Resources.resx, a Visual Studio custom tool sprang to life and created a C# class in the file Resources.Designer.cs. Among other things, the generated class contains a static property corresponding to each resource string—for example:

/// <summary>
///   Looks up a localized string similar to the President
/// </summary>
internal static string TheRuler {
    get {
        return ResourceManager.GetString("TheRuler", resourceCulture);
    }
}

This is almost exactly what you want. The only problem is that the autogenerated class and its properties are all marked as internal, which makes them inaccessible from your ASPX views (which compile as one or more separate assemblies). To resolve this, go back to Resources.resx and set its access modifier to public, as shown in Figure 17-13.

Figure 17-13. Making a resource class accessible outside its assembly

Now you can reference your resource strings in a strongly typed, IntelliSense-assisted way in your MVC views, as shown in Figure 17-14.

Figure 17-14. IntelliSense supports working with resource classes.

At runtime, ResourceManager will retrieve whatever value corresponds to the thread's CurrentUICulture. But how is this culture determined? By default, it's taken from your server's Windows settings, but a common requirement is to vary the culture for each visitor, inspecting the incoming Accept-Language header to determine their preferences.

One way to achieve this, which works perfectly well if you are only interested in the visitor's preferred culture while rendering ASPX views, is to add UICulture="auto" to your view's <%@ Page %> directive. That's not so useful if you might ever want to account for the visitor's culture during action methods or when rendering views using other view engines, so it's possibly better to add the following to your Global.asax.cs file:

protected void Application_BeginRequest(object sender, EventArgs e)
{
    // Uses Web Forms code to apply "auto" culture to current thread and deal with
    // invalid culture requests automatically
    using(var fakePage = new Page()) {
        var ignored = fakePage.Server;     // Work around a Web Forms quirk
        fakePage.Culture = "auto";         // Apply local formatting to this thread
        fakePage.UICulture = "auto";       // Apply local language to this thread
    }
}

If you prefer, you can inspect the incoming Accept-Language header values manually using Request.UserLanguages, but beware that clients might request unexpected or invalid culture settings. The previous example shows how, instead of parsing the header and detecting invalid culture requests manually, you can leverage the existing logic on Web Forms' Page class.

So now, depending on which language the visitor has configured in their browser, they'll see either one of the following (Figure 17-15).

Figure 17-15. Output for the localization example

The right-hand output corresponds to the browser language setting en-GB, and the left-hand output corresponds to anything else. The date and currency were formatted using Date.ToShortDateString() and string.Format("{0:c}", 1), respectively.

For all but the tiniest applications, you'll benefit from keeping your resources in a separate assembly. That makes it easier to manage in the long run, and means you can reference it from your other projects if needed.

To do this, create a new class library project, right-click it, and choose Add

There's one other trick worth considering. When you're editing MVC views all day long, you'll get tired of writing out MyResourcesProject.Resources.Something, so add the following global namespace registration to your Web.config file, and then you can just write Resources.Something:

<system.web>
  <pages>
    <namespaces>
      <add namespace="MyResourcesProject"/>
    </namespaces>
  </pages>
</system.web>

Of course, in most real localization scenarios, you'll want to localize entire phrases into totally different languages, not just individual words into different dialects. Within those phrases, you'll often need to inject other strings that come from your database or were entered by the user.

The usual solution is to combine the framework's localization features with string.Format(), using numbered placeholders, and the resource editor's Comment feature so your translation staff knows what each placeholder represents. For example, your default resource file might contain the placeholders shown in Figure 17-16.

Figure 17-16. A resource file with placeholders

Based on this, your translation staff can produce the Spanish resource file shown in Figure 17-17.

Figure 17-17. A corresponding resource file for es-ES culture

Then you can render a localized string from an view, as follows:

<%: string.Format(Resources.UserUpdated, ViewData["UserName"], DateTime.Now) %>

This renders the following by default:

The user "Bob" was updated at 1:46 PM

But for Spanish-speaking visitors, it renders this:

(13:46) El usuario "Bob" ha sido actualizado

Note how easy it is to vary sentence structures and even use different formatting styles. Complete phrases can be translated far more cleanly than individual sentence fragments such as "was updated at."

If internationalization is an important feature in your application, there are other topics you might want to consider, such as designing for right-to-left languages and handling non-Gregorian calendars. For more details, see .NET Internationalization, by Guy Smith-Ferrier (Addison-Wesley, 2006).

As you learned in Chapter 12, ASP.NET MVC has extensive support for client-side and server-side validation. You can express rules using Data Annotations attributes or implement your own custom validation provider. This brings up the question of how to globalize your validation rules (e.g., so that different cultures' date formats are respected) and how to localize validation error messages into different languages.

<script type="text/javascript">
    // Note: this must go *after* your script reference to MicrosoftAjax.js
    var numberFormat = Sys.CultureInfo.CurrentCulture.numberFormat;
    numberFormat.NegativeSign = "-";
    numberFormat.PositiveSign = "+";
    numberFormat.NumberDecimalSeparator = ",";
    numberFormat.NumberGroupSeparator = ".";
    numberFormat.NumberNegativePattern = 1;
</script>

protected void Application_Start()
{
    AjaxHelper.GlobalizationScriptPath =
            "http://ajax.microsoft.com/ajax/4.0/1/globalization/";
    // Leave the rest of this method unchanged
}

<%: Ajax.GlobalizationScript() %>
<script src="<%: Url.Content("~/Scripts/MicrosoftAjax.js") %>"
        type="text/javascript"></script>

<script type="text/javascript"
        src="http://ajax.microsoft.com/ajax/4.0/1/globalization/es-ES.js"></script>
<script src="/Scripts/MicrosoftAjax.js" type="text/javascript"></script>

The next consideration is how to display messages such as "This field is required" in different languages. If you've created a custom validation provider, it's up to you to implement your own mechanism for supplying localized messages. If you're using Data Annotations attributes, you can use their ErrorMessageResourceType and ErrorMessageResourceName properties to load messages from a resource file matching the thread's UI culture.

For example, create a resource file called ValidationMessages.resx anywhere in your project. Add resource strings such as those shown in Figure 17-18.

Figure 17-18. Custom validation messages in a resource file

Next, refer to these resource strings from your models' Data Annotations attributes as follows:

[Required(ErrorMessageResourceType = typeof(ValidationMessages),
          ErrorMessageResourceName = "Required")]
[RegularExpression(@".+@.+..+",
                   ErrorMessageResourceType = typeof(ValidationMessages),
                   ErrorMessageResourceName = "EmailAddress")]
public string ContactEmail { get; set; }

Now the framework will use your resource strings to supply messages for both server-side and client-side validation.

To support multiple languages, simply create additional resource files for each culture you wish to support. For example, to support Spanish, create a resource file called ValidationMessages.es-ES.resx, containing the same string names (in this example, that's Required and EmailAddress) along with the Spanish translations. The framework will automatically use these translations whenever the thread's UI culture equals es-ES.

public class ClientNumberValidatorProvider : ClientDataTypeModelValidatorProvider
{
   public override IEnumerable<ModelValidator> GetValidators(ModelMetadata metadata,
                                                          ControllerContext context)
   {
       bool isNumericField = base.GetValidators(metadata, context).Any();
       if (isNumericField)
           yield return new ClientSideNumberValidator(metadata, context);
   }
}

public class ClientSideNumberValidator : ModelValidator
{
  public ClientSideNumberValidator(ModelMetadata metadata,
      ControllerContext controllerContext) : base(metadata, controllerContext) { }

  public override IEnumerable<ModelValidationResult> Validate(object container)
  {
     yield break; // Do nothing for server-side validation
  }

  public override IEnumerable<ModelClientValidationRule> GetClientValidationRules()
  {
     yield return new ModelClientValidationRule {
        ValidationType = "number",
        ErrorMessage = string.Format(CultureInfo.CurrentCulture,
                                     ValidationMessages.MustBeNumber,
                                     Metadata.GetDisplayName())
        };
  }
}

protected void Application_Start()
{
    // Leave the rest of this method unchanged

    var existingProvider = ModelValidatorProviders.Providers
        .Single(x => x is ClientDataTypeModelValidatorProvider);
    ModelValidatorProviders.Providers.Remove(existingProvider);
    ModelValidatorProviders.Providers.Add(new ClientNumberValidatorProvider());
}

By default, the MVC Framework sends response data to browsers in a plain, uncompressed format. For example, textual data (e.g., HTML) is typically sent as a UTF-8 byte stream: it's more efficient than UTF-16, but nowhere near as tightly packed as it could be. Yet almost all modern browsers are happy to receive data in a compressed format, and they advertise this capability by sending an Accept-Encoding header with each request. For example, both Firefox 3 and Internet Explorer 7 send the following HTTP header:

Accept-Encoding: gzip, deflate

This means they're happy to accept either of the two main HTTP compression algorithms, gzip and deflate. In response, you use the Content-Encoding header to describe which, if any, of those algorithms you've chosen to use, and then compress the HTTP payload (which itself may still be UTF-8 or anything else) with that algorithm.

The .NET Framework's System.IO.Compression namespace contains ready-made implementations of both gzip and deflate compression algorithms, so it's very easy to implement the whole thing as a small action filter:

using System.IO;
using System.IO.Compression;

public class EnableCompressionAttribute : ActionFilterAttribute
{
    const CompressionMode compress = CompressionMode.Compress;
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        HttpRequestBase request = filterContext.HttpContext.Request;
        HttpResponseBase response = filterContext.HttpContext.Response;

string acceptEncoding = request.Headers["Accept-Encoding"];
        if (acceptEncoding == null)
            return;

        if (acceptEncoding.ToLower().Contains("gzip"))
        {
            response.Filter = new GZipStream(response.Filter, compress);
            response.AppendHeader("Content-Encoding", "gzip");
        }
        else if (acceptEncoding.ToLower().Contains("deflate"))
        {
            response.Filter = new DeflateStream(response.Filter, compress);
            response.AppendHeader("Content-Encoding", "deflate");
        }
    }
}

In this example, the filter chooses gzip if the browser supports it, and otherwise falls back on deflate. Now, once you've decorated one or more action methods or controllers with the [EnableCompression] attribute, you'll see a considerable reduction in bandwidth usage. For example, this action method:

[EnableCompression]
public void Index()
{
    // Output a lot of data
    for (int i = 0; i < 10000; i++)
        Response.Write("Hello " + i + "<br/>");
}

would naturally result in a 149 KB payload,^[119] but that's reduced to 34 KB because of [EnableCompression]—a savings of over 75 percent. You might expect that real-world data wouldn't compress so well, but in fact, a study of 25 major web sites found that HTTP compression yielded average bandwidth savings of 75 percent.^[120]

Compression saves on bandwidth, so pages load faster and users are happier. Plus, depending on your hosting scenario, bandwidth saved might equal money saved. But bear in mind that compression costs CPU time. What's more valuable to you, reduced CPU load or reduced bandwidth use? It's up to you to make a decision for your application—you might choose to enable compression only for certain actions methods. If you combine it with output caching, you can have both low bandwidth and low CPU usage; the cost switches to memory.

Don't forget that HTTP compression is only really useful for textual data. Binary data, such as graphics, is usually already compressed. You will not benefit by wrapping gzip compression around existing JPEG compression; you will just burn CPU cycles for nothing.

Even though it usually makes more business sense to optimize your application for maintainability and extensibility rather than for sheer performance (servers are cheaper than developers), there's still great value in keeping an eye on some carefully chosen performance metrics as you code.

That action method of yours used to run in 0.002 seconds, but after your recent amendment, it now takes 0.2 seconds. Did you realize? This factor-of-100 difference could be critical when the application is under production loads. And you assumed a certain action method ran 1 or 2 database queries, but sometimes it runs 50—not obvious during development; critical when live.

Dedicated load testing is useful, but by that stage you've written the code and perhaps built more code on top of it. If you could spot major performance issues earlier, you'd save a lot of effort. Fortunately, each part of your application stack offers tools to help you keep track of what's happening behind the scenes:

There are so many possibilities here; you must be able to get the information you need . . . somehow. However, it isn't always obvious how to get only the most pertinent information, and how to keep those key metrics effortlessly visible as an ongoing development consideration (and how to encourage your coworkers to do the same).

For a quick-and-easy way to keep track of performance characteristics, you can create a custom HTTP module that appends performance statistics to the bottom of each page generated. An HTTP module is just a .NET class implementing IHttpModule—you can put it anywhere in your solution. Here's an example that uses .NET's built-in high-resolution timer class, System.Diagnostics.Stopwatch:

public class PerformanceMonitorModule : IHttpModule
{
    public void Dispose() { /* Nothing to do */ }

    public void Init(HttpApplication context)
    {
        context.PreRequestHandlerExecute += delegate(object sender, EventArgs e)
        {
            HttpContext requestContext = ((HttpApplication)sender).Context;
            Stopwatch timer = new Stopwatch();
            requestContext.Items["Timer"] = timer;
            timer.Start();
        };
        context.PostRequestHandlerExecute += delegate(object sender, EventArgs e)
        {
            HttpContext requestContext = ((HttpApplication)sender).Context;
            Stopwatch timer = (Stopwatch)requestContext.Items["Timer"];
            timer.Stop();

            // Don't interfere with non-HTML responses

if (requestContext.Response.ContentType == "text/html")
            {
                double seconds = (double)timer.ElapsedTicks / Stopwatch.Frequency;
                string result =
                 string.Format("{0:F4} sec ({1:F0} req/sec)", seconds, 1 / seconds);
                requestContext.Response.Write("<hr/>Time taken: " + result);
            }
        };
    }
}

IHttpModule classes have to be registered in your application's Web.config file, via a node like this:

<add name="PerfModule" type="Namespace.PerformanceMonitorModule, AssemblyName"/>

For IIS 5/6, and for the Visual Studio built-in web server, add it to the system.web/httpModules section. For IIS 7.x, add it to the system.webServer/modules section (or use IIS 7.x's Modules GUI, which edits Web.config on your behalf).

Once you have PerformanceMonitorModule registered, you'll start seeing performance statistics, as shown in Figure 17-20.

Figure 17-20. Output from PerformanceMonitorModule appended to a page

That statistic alone is a key performance indicator. By building it into your application, you automatically share the insight with all other developers on your team. When you deploy to your production servers, just remove (or comment out) the module from your Web.config file.

Besides page generation time, the most important performance statistics usually relate to database access. That's because you can probably issue 100 queries to your own personal SQL Server instance in mere milliseconds, but if your production server tried to do the same for 100 concurrent clients, you'd be in trouble.

Also, if you're using an ORM tool such as LINQ to SQL, NHibernate, or Entity Framework, don't lose touch with reality. Even though you don't write much SQL yourself, there's still a whole lot of SQL going on under the surface. But how many queries happen, and are they well optimized? Do you have the famous SELECT N+1 problem?^[121] How will you know?

One option is to use SQL Server's Profiler tool: it displays every query in real time. However, that means you have to run SQL Profiler, and you have to keep remembering to look at it. And even if you do have a special monitor dedicated to SQL Profiler, it's still hard to work out which queries relate to which HTTP request. Fortunately, LINQ to SQL does its own internal query logging, so you can write an HTTP module to show the queries that were invoked during each request. This is much more convenient.

Add the following class to your solution:

public class SqlPerformanceMonitorModule : IHttpModule
{
    static string[] QuerySeparator
        = new string[] { Environment.NewLine + Environment.NewLine };

    public void Init(HttpApplication context)
    {
        context.PreRequestHandlerExecute += delegate(object sender, EventArgs e)
        {
            // Set up a new empty log
            HttpContext httpContext = ((HttpApplication)sender).Context;
            httpContext.Items["linqToSqlLog"] = new StringWriter();
        };

        context.PostRequestHandlerExecute += delegate(object sender, EventArgs e)
        {
            HttpContext httpContext = ((HttpApplication)sender).Context;
            HttpResponse response = httpContext.Response;

            // Don't interfere with non-HTML responses
            if (response.ContentType == "text/html") {
                var log = (StringWriter)httpContext.Items["linqToSqlLog"];
                var queries = log.ToString().Split(QuerySeparator,
                                            StringSplitOptions.RemoveEmptyEntries);
                RenderQueriesToResponse(response, queries);
            }
        };
    }

    void RenderQueriesToResponse(HttpResponse response, string[] queries)
    {
        response.Write("<div class='PerformanceMonitor'>");
        response.Write(string.Format("<b>Executed {0} SQL {1}</b>",

queries.Length,
                                    queries.Length == 1 ? "query" : "queries"));

        response.Write("<ol>");
        foreach (var entry in queries)
            response.Write(string.Format("<li>{0}</li>",
                           Regex.Replace(entry, "(FROM|WHERE|--)", "<br/>$1")));
        response.Write("</ol>");
        response.Write("</div>");
    }

    public void Dispose() { /* Not needed */ }
}

As usual, you need to register the HTTP module in your Web.config file, either under system.web/httpModules for IIS 5/6 and for the Visual Studio built-in web server, or under system.webServer/modules for IIS 7.x. Here's the syntax:

<add name="SqlPerf" type="Namespace.SqlPerformanceMonitorModule, AssemblyName"/>

This HTTP module starts each request by creating a new StringWriter object and storing it in the current HTTP context's Items collection. Later, at the end of the request, it retrieves that StringWriter, parses out SQL query data that has been inserted into it in the meantime, makes a vague effort to format it nicely by inserting line breaks and HTML tags, and injects it into the response stream.

That's great, but LINQ to SQL doesn't know anything about it, so it's not going to tell it about any queries. You can rectify this by hooking into your LINQ to SQL DataContext class's OnCreated() partial method. The way to do this depends on how you originally created your DataContext class:

This means that each time a data context is created, it will find the StringWriter that was created by SqlPerformanceMonitorModule, and use it as a log for any queries issued. If you have more than one DataContext class, hook them all up the same way.

The result of this is shown in Figure 17-21.

Figure 17-21. Output from SqlPerformanceMonitorModule appended to a page

If you're new to LINQ to SQL and you don't know how efficiently you're using it, then having this much clarity about what's happening is essential. And if you have developers on your team who don't trust ORM tools because of performance fears, show this to them and see if it helps to change their mind.