Looking into Autofac recently, I was trying to find a way of getting a logger property assigned as a component is created from the container in the same way as Windsor’s logging facility. The Autofac container has a Module/IModule extensibility which works well for the tasks a facility would have done.

Here’s the type of code I’m used to seeing from logging.

using Castle.Core.Logging;

namespace LoggingStudy {
    public interface IFoo {
        void Bar();
    }

    public class Foo : IFoo {
        public Foo() {
            Logger = NullLogger.Instance;
        }

        public ILogger Logger { get; set; }

        public void Bar() {
            Logger.Info("Bar called");
        }
    }
}

And here’s how you’d add a logging module to an Autofac builder.

using Autofac.Builder;

namespace LoggingStudy {

    class Program {
        static void Main(string[] args) {
            var builder = new ContainerBuilder();
            builder.RegisterModule(new LoggingModule());
            builder.Register<Foo>().As<IFoo>();

            var container = builder.Build();

            using (var scope = container.CreateInnerContainer()) {
                var foo = scope.Resolve<IFoo>();
                foo.Bar();
            }
        }
    }
}

And here’s an implementation of a LoggingModule that will use Castle’s ILoggerFactory to assign the ILogger typed public properties. Some of the code is based on a few threads in the discussion group.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using Autofac;
using Autofac.Builder;
using Castle.Core.Logging;

namespace LoggingStudy {
    public class LoggingModule : Autofac.Builder.Module {
        protected override void Load(ContainerBuilder moduleBuilder) {
            // by default, use Castle's TraceSource based logger factory
            moduleBuilder.Register<TraceLoggerFactory>().As<ILoggerFactory>().ContainerScoped();

            // call CreateLogger in response to the request for an ILogger implementation
            moduleBuilder.Register((ctx, ps) => CreateLogger(ctx, ps)).As<ILogger>().FactoryScoped();
        }

        protected override void AttachToComponentRegistration(IContainer container, IComponentRegistration registration) {
            var implementationType = registration.Descriptor.BestKnownImplementationType;

            // build an array of actions on this type to assign loggers to member properties
            var injectors = BuildLoggerInjectors(implementationType).ToArray();

            // if there are no logger properties, there's no reason to hook the activated event
            if (!injectors.Any())
                return;

            // otherwise, whan an instance of this component is activated, inject the loggers on the instance
            registration.Activated += (s, e) => {
                foreach (var injector in injectors)
                    injector(e.Context, e.Instance);
            };
        }

        private static IEnumerable<Action<IContext, object>> BuildLoggerInjectors(Type componentType) {
            // Look for settable properties of type "ILogger"
            var loggerProperties = componentType
                .GetProperties(BindingFlags.SetProperty | BindingFlags.Public | BindingFlags.Instance)
                .Select(p => new {
                    PropertyInfo = p,
                    p.PropertyType,
                    IndexParameters = p.GetIndexParameters(),
                    Accessors = p.GetAccessors(false)
                })
                .Where(x => x.PropertyType == typeof(ILogger)) // must be a logger
                .Where(x => x.IndexParameters.Count() == 0) // must not be an indexer
                .Where(x => x.Accessors.Length != 1 || x.Accessors[0].ReturnType == typeof(void)); //must have get/set, or only set

            // Return an array of actions that resolve a logger and assign the property
            foreach (var entry in loggerProperties) {
                var propertyInfo = entry.PropertyInfo;

                yield return (ctx, instance) => {
                    var propertyValue = ctx.Resolve<ILogger>(new TypedParameter(typeof(Type), componentType));
                    propertyInfo.SetValue(instance, propertyValue, null);
                };
            }
        }

        private static ILogger CreateLogger(IContext context, IEnumerable<Parameter> parameters) {
            // return an ILogger in response to Resolve<ILogger>(componentTypeParameter)
            var loggerFactory = context.Resolve<ILoggerFactory>();
            var containingType = parameters.TypedAs<Type>();
            return loggerFactory.Create(containingType);
        }
    }
}

The TraceLoggerFactory is added as a default ILoggerFactory. It’s my favorite one and because it’s based on System.Diagnostics TraceSource it doesn’t require additional assemblies.

If you expect to Resolve from a container you’ll need to add a TypedParameter for typeof(Type), because the logger factory needs that information. It also doesn’t work to provide an ILogger constructor parameter as it’s written, but if ILogger properties are what you’re looking for it should do the job.

So if you’re looking at adding automapper, or nhiberbate, or ioc xyz, you’re obviously going to be thinking about impact to CPU and memory.

And there are two type of memory impacts: load-and-hold and burn-rate (or memory pressure). The first is relatively easy to say you’re using ten megs of one-time cost memory in each appdomain once it’s initialized and warmed up. The other’s a bit more subtle - if a tool goes through a two megs of object, string, collection, buffer memory in a request - and say you’re tooling along with bursts of 25 req/sec - then 50meg/sec means you’ve given the garbage collector a gig of ram to recycle every 20 seconds. Numbers and needs vary but you get the idea that high burn rates end up causing a CPU tax to be paid affecting the net power availabe.

But on the other hand dotnet is a high level language, and a lot of there types of things are developer productivity tools - not performance tool - so they will *always* have measurable increase in cost. But in the most extreme cases, like from he point of view of a hosting company, you could almost assume that memory efficiency is directly proportional to hardware, space, and power costs per client…

Not that it’s a black and white situation, of course, but at what point are the conveniences and strengths of a library outweighed by the cost of using it? Of course it’s always difficult to weigh something subjective against something quantifiable.

But what’s your take on that?

For example, Building 42! My new home. I swear walking into the campus this morning I couldn’t keep the grin off my face.

Let’s see… What else is there. Ah! There are people in the building! To name a few there’s Bertrand Le Roy, Renaud Paquay, Bradley Millington… Ah, well. I’m not having much luck finding a public internet presence for a lot of people so I’ll leave off with the naming of names in case they prefer anonymity. There’s also people like Scott Guthrie and Phil Haack but that would be like pointing out the fact there are roads and trees around the building.

I’m actually feeling really good about the decision to join Microsoft. Met the team, surrounded by blindingly smart people, workstation fully installed, two beautiful monitors showed up today, getting a handle on where the project is at and where it’s going. End of the second day and it’s time to head home now.

The big news today is I’ve accepted a position at Microsoft, which is the final realization of an ambition of mine which started a year and a half ago. What hooked me then was watching the open style of development the ASP.NET MVC team was embracing and the great results and positive community feedback they were getting. I though to myself, if there was someplace you could choose to work that would be it.

I should add I’m not on the MVC team, but since I don’t know what’s public knowledge yet or not - please forgive me being vague.

Plus if anyone’s curious this doesn’t change the status of Spark regarding license, source, distribution, etc.

But yeah! Exciting! I have to finish up now and grab some coffee and prepare myself for a day of paperwork and hr presentations. Woohoo!

Today was the first of four days. Played a BattleTech bootcamp with Alex, some nostalgia there for me because that’s a game I the old group in high school used to play as well. He loved it - we’re going to be getting the intro box set when we get home.

Also signed up for an interactive action game TerrorWerks. Lots of fun. Three groups of five players armed with the soft yellow pellet assault rifles on an mission in a background that reminds you of the Aliens movies. I was an engineer (or course) and near the end of the mission was severely wounded and out of ammo, and eventually died trying to pull someone back from the end of a corridor where he was bleeding to death. Yay!

Going to run now to and catch an anime “Berserk” being screened. :)

I had the opportunity the other day to read through Beginning ASP.NET MVC 1.0 written by Simone Chiaretta and Keyvan Nayyeri. I like how it’s structured if you may be learning about the concepts from scratch.

The first I had heard about the book was quite a while ago when Simone sent me a few questions about Spark. In the later chapters about extending ASP.NET MVC there’s a small section that describes various alternate view engines. I have to admit that’s the first place I flipped to. :)

I especially the fact that after covering the basics early on almost sixty pages are dedicated to unit testing concepts and it’s implementation for MVC applications. A lot of times in demos and articles even though the importance of testing or TDD is stressed it seems like you don’t walk away with something actionable if you’re new to those practices.

Also ends with some real-world samples… Ah - and all of the code is downloadable from wrox.com. Very nice.

Part of this comes back to Phil’s blog post about Donut Hole Caching in ASP.NET MVC. Especially below where he writes, as he’s thinking out loud, “This would have to work in tandem with some means to specify that the bit of view data intended for the partial view is only recreated when the output cache is expired for that partial view, so we don’t incur the cost of creating it on every request.”

I have to admit I’m not necessarily a huge fan of the built-in ASP.NET page caching directives… Also didn’t particularly care for the forced alignment of partial-boundaries and cache-boundaries. I would hate to have a larger number of smaller files on disk simply because that’s the breakdown at which I wanted to cache the individual parts. In an ideal world I would like to be able to quickly and easily mark an expensive bit as cacheable, and provide the caching details that relate specifically to that bit, and be done with it.

So - enter Spark caching:

stuff
<cache key="employeeId" expires="300">
  this is stuff about the employee
</cache>
stuff

Kind of simple, really. The key works like the <%@OutputCache%> VaryByParam value, but it can be a comma delimited csharp expressions of anything which makes the cached information unique.

There’s a ICacheSignal interface which takes the place of custom CacheDependency classes in the ASP.NET caching framework.

public interface ICacheSignal
{
    event EventHandler Changed;
}

If you want fine-grained control to clear out-of-date cached data you would provide an instance of your implementation of this signal, or you can use the built-in ChangeSignal class. So that could be something as simple as:

stuff
<cache key="employeeId" signal="MyApp.Signals.EmployeeTables">
  this is stuff about the employee
</cache>
stuff

public static class Signals
{
  public static ChangeSignal EmployeeTables = new ChangeSignal();
}

You app would need to provide the glue to watch the tables and call Signals.EmployeeTables.FireChanged() of course. It does require a bit more effort, but you’re free to implement your signaling down to whatever level of granularity you would like. If you cache all of the comment html on a blog post, for example, you could keep a dictionary of change signals per-post-id around to drop exactly the correct amount of cached information when a comment is added or removed.

The implementation was a bit tricky in parts, but it should support the all of the cases where once attributes and named content are used inside or around cache elements.

Ah, yes! Back to the original need for avoiding the cost of gathering view data when the related bit of the view is cached. For that you’d use a trick with a ValueHolder class which enables you to keep your data acquisition code in the controller’s action, yet enables a cache hit to avoid the cost of that data acquisition.

public ActionResult Details(int id)
{
    var data = new NorthwindDataContext();

    ViewData["employeeId"] = id;

    ViewData["employee"] = ValueHolder.For(
        () => data.Employees.Single(x => x.EmployeeID == id));

    return View();
}

In that case for example you could have a cache key=”employeeId” and only use the employee.Value property inside that cache. That way if the html for that section (for that employeeId) has already been created and stored, then the second time through .Value property will never be used and the lambda will never be executed. For example:

<viewdata employeeId="int" employee="ValueHolder[[Employee]]" />
<cache key="employeeId">
  <h3>${employee.Value.FirstName} ${employee.Value.LastName}</h3>
  this is stuff about employee number ${employee.Value.EmployeeID}.
</cache>

So that’s a kind of nice way to cut out WCF and SQL costs without violating MVC best practices by having your views fetch data. After all it’s almost never the rendering costs that are the real problem in the first place.

There’s also a trick you can use with <viewdata> to get rid of the .Value. when you’re using the object inside a ValueHolder.

<viewdata employeeId="int" employee.Value="Employee employee" />
<cache key="employeeId">
  <h3>${employee.FirstName} ${employee.LastName}</h3>
  this is stuff about employee number ${employee.EmployeeID}.
</cache>

Updated, in answer to Adam’s question in the comments

A value holder can also by used inside of a strongly typed model, like this.

public class EmployeeDetailsModel
{
    // lazy-loaded data
    public ValueHolder<int, Employee> EmployeeHolder {get;set;}

    // aliasing .Key and .Value
    public int EmployeeID {get {return EmployeeHolder.Key;} }
    public Employee Employee {get {return EmployeeHolder.Value;} }
}

public ActionResult Details(int id)
{
    var data = new NorthwindDataContext();

    var model = new EmployeeDetailsModel
    {
        EmployeeHolder = ValueHolder.For(id,
            key => data.Employees.Single(x => x.EmployeeID == key))
    };

    return View(model);
}

And the usage in the view is about what you would expect.

<viewdata model="EmployeeDetailsModel" />
<cache key="Model.EmployeeID">
  <h3>${Model.Employee.FirstName} ${Model.Employee.LastName}</h3>
  this is stuff about employee number ${Model.Employee.EmployeeID}.
</cache>

Putting Lipstick on a Web Site

To start with there are a few ground rules and goals to establish. One is that a 301 permanent redirect is desirable from older urls onto new routed urls. Another is that not all urls in the app need to be fixed “in place” in the original html response assuming the 301 redirects will keep the resulting urls canonical. Third is that it’s highly desirable to be able to calculate the new route given an old url server-side, for such things as the site map and updating the links on pages which are particularly significant.

Another consideration is that if a site is currently using Request.QueryString values and relies on postback, both of those should continue to work transparently. A final consideration is the range of possible values in a piece of the route could be driven by a database or source which is non-static or has a huge number of possible distinct values. At least a number too large for adding multiple routes or combining into regex restriction.

Downloads: retrofit.zip source code and sample project.

It turns out the System.Web.Routing module is particularly well suited for this, especially because of the bidirectional nature of it’s routes. The attached solution has a sample web app and a class library named Retrofit.Routing which provides an example of using System.Web.Routing in this way.

First of all is the class Retrofit.Routing.WebFormsRouteHandler which implements IRouteHandler. You’ll find in it’s implementation the method GetHttpHandler which will use BuildManager.CreateInstanceFromVirtualPath to obtain an instance of the targetted web page. The web page is targetted with the RouteData Value parameter named “VirtualPath”, much like in an MVC app the controller is targetted with a RouteData Value named “Controller”. The other thing this class does is call HttpContext.RewritePath to extend the number of values present on the QueryString.

You won’t use the WebFormsRouteHandler directly, instead you’ll create an instance of WebFormsRoute. This WebFormsRoute is a descendant of the standard Route class and is used in almost exactly the same way.

public static void RegisterRoutes(RouteCollection routes)
{
    // enable routing of existing files so WebFormsRoute has the chance redirect old urls
    routes.RouteExistingFiles = true;

    // matches customer with a data-driven constraint
    routes.Add(new WebFormsRoute(
        "Customer/{*CompanyName}",
        new RouteValueDictionary(new {VirtualPath = "~/Contacts/Customer.aspx"}),
        new RouteValueDictionary(new {CompanyName = new ValidCompanyNameConstraint()})
    ));

    // matches orders requests
    routes.Add(new WebFormsRoute(
        "Customer/Orders/{OrderID}",
        new RouteValueDictionary(new {VirtualPath = "~/Orders/Details.aspx"})
    ));

}

As we can see defaults can be provided, which is how the value for VirtualPath is defaulted in when a request pattern is matched. The values like {CompanyName} and {OrderID} which are matched above will become CompanyName= and OrderID= querystring parameters passed to the aspx page as it runs, so the code behind does not need to be modified for those cases.

There’s even an example above of how you would provide an IRouteConstraint class if you would like to dynamically restrict the set of urls a route is allowed to match.

public class ValidCompanyNameConstraint : IRouteConstraint
{
    public ValidCompanyNameConstraint()
    {
        // pre-load valid company names
        // in a real app this would be queries each call to match,
        // or it would be re-cached when the data had changed.

        var data = new NorthwindDataContext();
        CachedNames = data.Customers.ToDictionary(x => x.CompanyName, x => x.CustomerID);
    }

    private Dictionary<string, string> CachedNames { get; set; }

    public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection)
    {
        var parameterValue = Convert.ToString(values[parameterName]);
        return CachedNames.ContainsKey(parameterValue);
    }
}

It’s a contrived example, but it is just a sample after all.

And the WebFormsRoute is performing one other task related to the need for 301 redirects. As requests are coming in it’s not only matching the request against the new url pattern, it’s also testing the request url against the old virtual path and query string parameters needed.

    // do the work to check if the incoming request could also produce
    // a meaningful route to redirect towards
    var probeVirtualPathData = TestVirtualPath(httpContext, virtualPath);
    if (probeVirtualPathData == null)
        return null;

    // the request is on a page which this route controls, 301 redirect
    // onto the correct location
    return new RouteData(this, new PermanentRewriteHandler(probeVirtualPathData.VirtualPath));
}

If the incoming request is match for the old url structure then it takes advantage System.Web.Routing’s ability to calculate the correct url in the new pattern. This new url is used as the parameter of a handler which will return a 301 permanent redirect to keep the browser’s address bar clean-looking and to ensure web crawlers are indexing the site with at this single, canonical location.

The rewrite handler itself is a pretty simple device.

public class PermanentRewriteHandler : IRouteHandler, IHttpHandler
{
    private readonly string _path;

    public PermanentRewriteHandler(string path)
    {
        _path = path;
    }

    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        return this;
    }

    public bool IsReusable
    {
        get { return false; }
    }

    public void ProcessRequest(HttpContext context)
    {
        context.Response.Buffer = true;
        context.Response.Redirect("~/" + _path, false);
        context.Response.StatusCode = 301;
        context.Response.StatusDescription = "Moved Permanently";
    }
}

At this point nearly all of the goals are met. You can route incoming requests on new urls onto existing WebForms pages, it will 301 redirect incoming old urls onto the new location, the route values are converted to querystring values transparently, and POST to the WebForms life-cycle will pass through unimpeded on the old or new urls.

The final piece of the puzzle is the need to return the new urls in links returned from pages on the server without relying on the 301 redirects. That’s done easily enough with an extension method Page.ResolveRouteUrl that is used in the same way as Page.ResolveUrl.

public static string ResolveRouteUrl(this Page page, string relativeUrl)
{
    var url = relativeUrl;

    var virtualPathData = GetVirtualPathData(relativeUrl);
    if (virtualPathData != null)
    {
        url = "~/" + virtualPathData.VirtualPath;
    }

    return page.ResolveUrl(url);
}

And it’s used like this:

Company: <asp:HyperLink ID="HyperLink1" runat="server"
                NavigateUrl='<%# Page.ResolveRouteUrl("~/Contacts/Customer.aspx?CompanyName=" + Eval("CompanyName")) %>' Text='<%# Eval("CompanyName") %>'></asp:HyperLink>

Downloads: retrofit.zip source code and sample project.

In a nutshell - duct tape a tongs to the end of a spatula for length. Use the spatula to slice spam into 8mm slices. Place single slice on spatula and wrap around with tin foil, twisting like hard candy wrapper. Cook liberally over fire, unwrap carefully, put on hamburger bun and spray with pressurized cheese in a can. Enjoy.

Brenda swore by them. A warning however - have only one without an antacid on hand.

There was a brilliant fireworks display on the fourth with dozens of cakes of two- and three-inch mortars. Long story short Brenda’s cousin was involved in the show and I was enlisted to be perimeter security. So with flashlights in hand as Brenda and I watched for anyone who would may have wandered up to the launching area and we had point blank view of the show. Didn’t get hit by much debris at all. :)