So the scenario is one where you have a thing that can be extended with additional data. And capabilities, of course, but this post is just about the data. In a traditional app it’s very straightforward to add additional fields when a new feature is added.

Consider a thing with foo and bar fields, before:

And adding the thing with frap and quad fields, after:

This might not be the best way to go in a dynamic system. If the feature was strictly optional some users wouldn’t choose to activate it at all, so adding columns to a core table would be bad. Maybe not all of the things in the system would use the frap-quad fields, so having a very large number of (null) fields could be nice to avoid. In those cases a vertical data partition could be a nice approach.

In fact let’s go the extra step and make a core Thing record, with a ThingType, and move the foo and bar fields onto their own vertical record partition.

Now that’s starting to look a bit crazy, but that’s really the split-up view of a single logical entity. The goal behind breaking them apart is to have Frappable and FooBar aspects mutually ignorant of each other. In the end the logical view of entity #6 is still just the following:

Now let’s wire that together with some data NHibernate classes and Fluent NHibernate.

public class ThingType {
    public virtual int Id { get; set; }
    public virtual string Name { get; set; }
}

public class Thing {
    public virtual int Id { get; set; }
    public virtual ThingType ThingType { get; set; }
}

public class FooBar {
    public virtual int Id { get; set; }
    public virtual Thing Thing { get; set; }
    public virtual string Foo { get; set; }
    public virtual string Bar { get; set; }
}

public class Frappable {
    public virtual int Id { get; set; }
    public virtual Thing Thing { get; set; }
    public virtual string Frap { get; set; }
    public virtual string Quad { get; set; }
}

As a quick sample let’s use a console app to create and populate a database.

static void Main(string[] args) {
    var database = SQLiteConfiguration.Standard.UsingFile("DataSample.db").ShowSql();
    var model = AutoMap.Assembly(typeof(Thing).Assembly);

    var sessionFactory = Fluently.Configure()
        .Database(database)
        .Mappings(mappings => mappings.AutoMappings.Add(model))
        .ExposeConfiguration(config => new SchemaExport(config).Execute(false, true, false))
        .BuildSessionFactory();

    Console.WriteLine("Adding records");
    var session = sessionFactory.OpenSession();
    var fooType = new ThingType { Name = "foo" };
    var fooPlusType = new ThingType { Name = "fooplus" };

    var thing = new Thing { ThingType = fooPlusType };
    var fooBar = new FooBar { Thing = thing, Foo = "brillig", Bar = "slithe" };
    var frappable = new Frappable { Thing = thing, Frap = "did", Quad = "and" };

    session.Save(fooType);
    session.Save(fooPlusType);
    session.Save(thing);
    session.Save(fooBar);
    session.Save(frappable);
    session.Close();

    Console.WriteLine("Fetching thing #{0}", thing.Id);
    session = sessionFactory.OpenSession();
    var fetch = session.Get<Thing>(thing.Id);
    Console.WriteLine(fetch.ThingType.Name);
    session.Close();
}

And the console output is this

Adding records
NHibernate: INSERT INTO "ThingType" (Name) VALUES (@p0); select last_insert_rowid();@p0 = 'foo'
NHibernate: INSERT INTO "ThingType" (Name) VALUES (@p0); select last_insert_rowid();@p0 = 'fooplus'
NHibernate: INSERT INTO "Thing" (ThingType_id) VALUES (@p0); select last_insert_rowid();@p0 = 2
NHibernate: INSERT INTO "FooBar" (Foo, Bar, Thing_id) VALUES (@p0, @p1, @p2); select last_insert_rowid();@p0 = 'brillig', @p1 = 'slithe', @p2 = 1
NHibernate: INSERT INTO "Frappable" (Frap, Quad, Thing_id) VALUES (@p0, @p1, @p2); select last_insert_rowid();@p0 = 'did', @p1 = 'and', @p2 = 1
Fetching thing #1
NHibernate: SELECT thing0_.Id as Id1_0_, thing0_.ThingType_id as ThingType2_1_0_ FROM "Thing" thing0_ WHERE thing0_.Id=@p0;@p0 = 1
NHibernate: SELECT thingtype0_.Id as Id0_0_, thingtype0_.Name as Name0_0_ FROM "ThingType" thingtype0_ WHERE thingtype0_.Id=@p0;@p0 = 2
fooplus
Press any key to continue . . .

As expected so far it’s not really a one-to-zero-or-one relationship. The FooBar.Id is an identity column generated by the table instead of copied from Thing.Id, and there really shouldn’t be a FooBar.Thing_id column at all. Let’s update that with an automapping alteration…

class Alteration : IAutoMappingAlteration {
    public void Alter(AutoPersistenceModel model) {
        model.Override<FooBar>(map => {
            map.Id(x => x.Id).GeneratedBy.Foreign("Thing");
            map.HasOne(x => x.Thing).Constrained();
        });
        model.Override<Frappable>(map => {
            map.Id(x => x.Id).GeneratedBy.Foreign("Thing");
            map.HasOne(x => x.Thing).Constrained();
        });
    }
}
// and in the main() method
    var model = AutoMap.Assembly(typeof(Program).Assembly)
        .Alterations(alt => alt.Add(new Alteration()));

And the console output is now:

Adding records
NHibernate: INSERT INTO "ThingType" (Name) VALUES (@p0); select last_insert_rowid();@p0 = 'foo'
NHibernate: INSERT INTO "ThingType" (Name) VALUES (@p0); select last_insert_rowid();@p0 = 'fooplus'
NHibernate: INSERT INTO "Thing" (ThingType_id) VALUES (@p0); select last_insert_rowid();@p0 = 2
NHibernate: INSERT INTO "FooBar" (Foo, Bar, Id) VALUES (@p0, @p1, @p2);@p0 = 'brillig', @p1 = 'slithe', @p2 = 1
NHibernate: INSERT INTO "Frappable" (Frap, Quad, Id) VALUES (@p0, @p1, @p2);@p0 = 'did', @p1 = 'and', @p2 = 1
Fetching thing #1
NHibernate: SELECT thing0_.Id as Id1_0_, thing0_.ThingType_id as ThingType2_1_0_ FROM "Thing" thing0_ WHERE thing0_.Id=@p0;@p0 = 1
NHibernate: SELECT thingtype0_.Id as Id0_0_, thingtype0_.Name as Name0_0_ FROM "ThingType" thingtype0_ WHERE thingtype0_.Id=@p0;@p0 = 2
fooplus
Press any key to continue . . .

That’s closer to what we’re looking for. Note the FooBar.Id is an inserted field now where it’s value comes from the Thing property, and the Thing_id column is gone from the schema.

The Id/Thing pair and override become cut-and-paste noise pretty quickly though, so we can factor those into an abstract base class and even make the HasOne alteration work on all data classes descended from it. Like this:

public abstract class ThingPart {
    public virtual int Id { get; set; }
    public virtual Thing Thing { get; set; }
}

class Alteration : IAutoMappingAlteration {
    public void Alter(AutoPersistenceModel model) {
        model.OverrideAll(map => {
            var recordType = map.GetType().GetGenericArguments().Single();
            if (recordType.IsAssignableFrom(typeof(ThingPart))) {
                var changeType = typeof(Change<>).MakeGenericType(recordType);
                var change = (IChange)Activator.CreateInstance(changeType);
                change.Go(map);
            }
        });
    }

    interface IChange {
        void Go(object mapObject);
    }

    class Change<TRecord> : IChange where TRecord : ThingPart {
        void IChange.Go(object mapObject) {
            var map = (AutoMapping<TRecord>)mapObject;
            map.Id(x => x.Id).GeneratedBy.Foreign("Thing");
            map.HasOne(x => x.Thing).Constrained();
        }
    }
}

There! In the end the following is all you need for an extension to add a new handful of fields onto thing.

public class FooBar : ThingPart {
    public virtual string Foo { get; set; }
    public virtual string Bar { get; set; }
}

public class Frappable : ThingPart {
    public virtual string Frap { get; set; }
    public virtual string Quad { get; set; }
}

There are some more tricks you need to query across several parts at once, but that’s probably another blog post on it’s own.

In the thread Howard says, among other things:

For those who are interested - here’s a little more info:

- We ran the project using Scrum and delivered in 20 weeks: 10 x 2 week iterations
- It’s based on the S#arp Architecture framework, which we extended to support Spark and ViewModels
- Integrated other OSS projects into the solution the one most relevant to Spark being N2CMS
- Solution performs very well: 1000 concurrent users per web server, generating around 180 pages per second across 2x single quad core 64bit servers.
- The site has a YSlow B Grading.

Very nice. His associate James Broome also has a post talking about their project as it relates to Asp.Net MVC – Separation of concerns amongst team members. You’ve gotta love hearing real-world examples of where UI-centric concerns and coding-centric concerns can work together in the same space at top speed without stumbling over each other’s focus.

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>