First, we need to apply a where clause to all queries to ensure that each tenant sees only their data. This is pretty painless with NHibernate and completely transparent to the existing application! We just have to define a parameterized filter:

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">

  <filter-def name="tenant">

    <filter-param name="id" type="System.Int32" />

  </filter-def>

</hibernate-mapping>

And then apply it to each entity:

<class name="User" table="[user]">

  <id name="Id" column="user_id">

    <generator class="identity" />

  </id>

  <property name="Username" />

  <property name="Email" />

  <filter name="tenant" condition="tenant_id = :id" />

</class>

The last step is to set the value of the filter at runtime. This is done on the ISession like this:

Container

    .RegisterType<ISession>(

        new PerRequestLifetimeManager(),

        new InjectionFactory(c =>

        {

            var session = c.Resolve<ISessionFactory>().OpenSession();

            session.EnableFilter("tenant").SetParameter("id", c.Resolve<Tenant>().Id);

            return session;

        })

    );

The current tenant comes from c.Resolve<Tenant>(). In order for that to work, you have to tell Unity how to find the current tenant. In ASP.NET MVC, we can look at the host header on the request and find our tenant that way. We could just as easily use another strategy though. Maybe if this were a WCF service, we could use an authentication header to establish the current tenant context. You could build out some interfaces and strategies around establishing the current tenant context, however for this article I’ll just bang it out.

Container

    .RegisterType<Tenant>(new InjectionFactory(c =>

    {

        var repository = c.Resolve<ITenantRepository>();

        var context = c.Resolve<HttpContextBase>();

        var host = context.Request.Headers["Host"] ?? context.Request.Url.Host;

        return repository.FindByHost(host);

    }));

Second, we have to set the tenant_id when new entities are saved. This is a bit more complicated with NHibernate and requires a bit of a concession in that we have to add a field to the entity in order for NHibernate to know how to persist the value. I’m using a private nullable int for this.

public class User

{

    private int? tenantId;

    public virtual int Id { get; set; }

    public virtual string Username { get; set; }

    public virtual string Email { get; set; }

}

It’s private because I don’t want the business logic to deal with it and it’s nullable because my tenant table is in a separate database which means I can’t lean on the data model to enforce referential integrity. That’s a problem because the default value for an integer is zero which could be happily saved by the database. By making it nullable I can be sure the database will blow up if the tenant_id is not set.

So, back to the issue at hand. The tenant_id needs to be set when the entity is saved. For this, I’m using an interceptor and setting the value in the OnSave method:

public class MultiTenantInterceptor : EmptyInterceptor

{

    private readonly Func<Tenant> tenant;

    public MultiTenantInterceptor(Func<Tenant> tenant)

    {

        this.tenant = tenant;

    }

    public override bool OnSave(object entity... object[] state, string[] propertyNames...)

    {

        var index = Array.IndexOf(propertyNames, "tenantId");

        if (index == -1)

            return false;

        var tenantId = tenant().Id;

        state[index] = tenantId;

        entity

            .GetType()

            .GetField("tenantId", BindingFlags.Instance | BindingFlags.NonPublic)

            .SetValue(entity, tenantId);

        return false;

    }

}

This IInterceptor mechanism is a little wonky. If you change any data, you have to do it in both the entity instance and the state array that NHibernate uses to hydrate entities. It’s not a big deal, it’s just one of those things you have to accept like the fact that Apple and Google are tracking your every move via your smart phone. Oh, and the interceptor gets wired up like this:

Container

    .RegisterType<ISessionFactory>(

        new ContainerControlledLifetimeManager(),

        new InjectionFactory(c =>

        {

            return new NHibernate.Cfg.Configuration()

                .Configure()

                .SetInterceptor(new MultiTenantInterceptor(() => c.Resolve<Tenant>()))

                .BuildSessionFactory();

        })

    );

We’re almost done. There is one more case that needs to be handled. When NHibernate loads an entity by its primary key, it doesn’t run through the query engine which means the tenant filter isn’t applied. Fortunately, we can take care of this in the interceptor:

public class MultiTenantInterceptor : EmptyInterceptor

{

    ...

    public override bool OnLoad(object entity... object[] state, string[] propertyNames...)

    {

        var index = Array.IndexOf(propertyNames, "tenantId");

        if (index == -1)

            return false;

        var entityTenantId = Convert.ToInt32(state[index]);

        var currentTenantId = tenant().Id;

        if (entityTenantId != currentTenantId)

        {

            throw new AuthorizationException("Permission denied to {0}", entity);

        }

        return false;

    }

}

That’s it. Have fun and happy commingling.

Build a web application as though it’s for a single customer (tenant) and add multi-tenancy as a bolt-on feature by writing only new code. There are flavors of multi-tenancy, in this case I want each tenant to have its own database but I want all tenants to share the same web application and figure out who’s who by looking at the host header on the http request.

The Plan:

To pull this off, we’re going to have to rely on our SOLID design principles, especially Single Responsibility and Dependency Inversion. We’ll get some help from these frameworks:

• ASP.NET MVC
• Unity
• NHibernate

Game on:

Let’s take a look at a controller that uses NHibernate to talk to the database. I’m not going to get into whether you should talk directly to NHibernate from the controller or go through a service layer or repository because it doesn’t affect how we’re going to add multi-tenancy. The important thing here is that the ISession is injected into the controller, and we aren’t using the service locator pattern to request the ISession from a singleton.

public class UserController : Controller

{

    private readonly ISession session;

    public UserController(ISession session)

    {

        this.session = session;

    }

    public ActionResult Edit(int id)

    {

        var user = session.Load<User>(id);

        return View(user);

    }

}

Alright, now it’s time to write some new code and make our web application connect to the correct database based on the host header in the http request. First, we’ll need a database to store a list of tenants along with the connection string for that tenant’s database. Here’s my entity:

public class Tenant

{

    public virtual string Name { get; set; }

    public virtual string Host { get; set; }

    public virtual string ConnectionString { get; set; }

}

I’ll use the repository pattern here so there is a crisp consumer of the ISession that connects to the lookup database rather than one of the tenant shards. This will be important later when we go to configure Unity.

public class NHibernateTenantRepository : ITenantRepository

{

    private readonly ISession session;

    private readonly HttpContextBase context;

    public NHibernateTenantRepository(ISession session, HttpContextBase context)

    {

        this.session = session;

        this.context = context;

    }

    public Tenant Current

    {

        get

        {

            var host = context.Request.Headers["Host"];

            return FindByHost(host);

        }

    }

    public Tenant FindByHost(string host)

    {

        return session

            .Query<Tenant>()

            .SingleOrDefault(t => t.Host == host);

    }

}

So now we need a dedicated ISessionFactory for the lookup database and make sure that our NHibernateTenantRepository gets the right ISession . It’s not too bad, we just need to name them in the container so we can refer to them explicitly.

Container

    .RegisterType<ISessionFactory>(

        "tenant_session_factory",

        new ContainerControlledLifetimeManager(),

        new InjectionFactory(c =>

            new NHibernate.Cfg.Configuration().Configure().BuildSessionFactory())

    );

Container

    .RegisterType<ISession>(

        "tenant_session",

        new PerRequestLifetimeManager(),

        new InjectionFactory(c =>

            c.Resolve<ISessionFactory>("tenant_session_factory").OpenSession())

    );

Container

    .RegisterType<ITenantRepository, NHibernateTenantRepository>()

    .RegisterType<NHibernateTenantRepository>(

        new InjectionConstructor(

            new ResolvedParameter<ISession>("tenant_session"),

            new ResolvedParameter<HttpContextBase>()

        )

    );

Hopefully that’s about what you were expecting since it’s not really the interesting part. The more interesting part is configuring the ISession that gets injected into the UserController to connect to a different database based on the host header in the http request. The Unity feature we’re going to leverage for this is the LifetimeManager. This is an often overlooked feature of IoC containers.

Container

    .RegisterType<ISessionFactory>(

        new PerHostLifetimeManager(() => new HttpContextWrapper(HttpContext.Current)),

        new InjectionFactory(c =>

        {

            var connString = c

                .Resolve<ITenantRepository>()

                .Current

                .ConnectionString;

            return new NHibernate.Cfg.Configuration()

                .Configure()

                .SetProperty(NHibernate.Cfg.Environment.ConnectionString, connString)

                .BuildSessionFactory();

        }));

Container

    .RegisterType<ISession>(

        new PerRequestLifetimeManager(),

        new InjectionFactory(c => c.Resolve<ISessionFactory>().OpenSession())

    );

Here we’re using a custom PerHostLifetimeManager. This tells Unity to maintain a session factory per host. When Unity runs across a host it doesn’t have a session factory for, it will run the InjectionFactory block to create one using the connection string associated with that tenant.

Since multiple simultaneous requests will be trying to get and set values with the same key, we need to make sure our PerHostLifetimeManager is thread safe. That’s pretty easy since Unity comes with a SynchronizedLifetimeManager base class that takes care of the fact that Dictionary isn’t thread safe.

public class PerHostLifetimeManager : SynchronizedLifetimeManager

{

    private readonly Func<HttpContextBase> context;

    private readonly IDictionary<string, object> store;

    public PerHostLifetimeManager(Func<HttpContextBase> context)

    {

        this.context = context;

        store = new Dictionary<string, object>();

    }

    protected override object SynchronizedGetValue()

    {

        var host = GetHost();

        if (!store.ContainsKey(host))

            return null;

        return store[host];

    }

    protected override void SynchronizedSetValue(object newValue)

    {

        store[GetHost()] = newValue;

    }

    private string GetHost()

    {

        return context().Request.Headers["Host"];

    }

}

So what did we accomplish? Well we didn’t touch any of our existing application code. We just wrote new code and through configuration we added multi-tenancy! That’s pretty cool, but was it worth it? Well, the goal in itself isn’t super important, but this exercise can certainly highlight areas of your codebase where you might be violating the single responsibility principle or leaking too many infrastructure concepts into your application logic.

public UserIndexViewModel GetIndexViewModel(int pageSize, int pageNumber) {
    var model = new UserIndexViewModel();

    var allUsers = Session.CreateCriteria<User>();

    model.Total = CriteriaTransformer
        .TransformToRowCount(allUsers)
        .UniqueResult<int>();

    model.Users = allUsers
        .SetFirstResult(pageSize * (pageNumber - 1) + 1)
        .SetMaxResults(pageSize)
        .AddOrder<User>(u => u.LastName, Order.Asc)
        .List<User>();

    return model;
}

There isn’t much going on here, but it could be better. I’m looking at the arguments pageSize and pageNumber. Notice how they both start with the prefix “page”. That’s a smell. The common prefix means the arguments are related, so let’s apply the Introduce Parameter Object refactoring and see what happens.

public class Page {
    private readonly int number;
    private readonly int size;

    public Page(int number, int size) {
        this.number = number;
        this.size = size;
    }

    public int Size {
        get { return size; }
    }

    public int Number {
        get { return number; }
    }

    public int FirstResult {
        get { return size * (number - 1) + 1; }
    }
}

What did we accomplish?

• Creating the parameter object gave us a place to put the logic of calculating the first result of the current page. This logic would otherwise be scattered around the application and even though it’s simple, it’s error prone.
• The logic of calculating the first result is testable.

[Test]
public void Should_calculate_first_result_of_current_page() {
    Assert.That(new Page(1, 20).FirstResult, Is.EqualTo(1));
    Assert.That(new Page(2, 20).FirstResult, Is.EqualTo(21));
    Assert.That(new Page(3, 20).FirstResult, Is.EqualTo(41));
}

It’s not rocket science, but it still deserves a test. Our other option is spinning up Cassini and clicking around to make sure we got it right. That’s just silly. A little piece of me dies each time I press F5 to run a manual test.

Anyway, there is this thing that happens with single responsibility classes. Because their purpose is crisp, it draws out robustness. In this case, I’m thinking about what we should we do if we get zero or a negative value for page number. I’m a fail fast kind of guy, so I’d probably go with a guard clause.

public Page(int number, int size) {
    GuardAgainstLessThanOne(number);
    ...
}

But you could silently correct it if that’s how you roll:

public int Number {
    get { return Math.Max(1, number); }
}

The point is that this is an obvious scenario to consider when looking at such a special purpose object. All too often though, bits of logic are mixed together like 32 kindergarteners sitting next to each other on a rug during a lesson. The room is one fart or tickle away from erupting into total kaos. It’s roughly half teaching and half crowd control, only without the rubber bullets and pepper spray. Not surprisingly, overcrowded classrooms don’t work that well and over-ambitous functions don’t work that well either. Each little bit of logic needs some one on one with you. Give it a chance to be all it can be by pulling it aside and getting to know it a little better. You might be surprised.

Figure A.5 Not enough time to test reduces the available time
Test-Driven Development: By Example by Kent Beck

It didn’t start out that way. In fact the first few lines of code I wrote were tests. The problem was I could only get about an hour or two in each night and every day that passed we were leaving money on the table.

Since I didn’t have much time at night, I didn’t want to spend it writing tests. I just wanted to get the app done. All I needed to do was sync business listings from an affiliate with GarageCommerce.com, the project I’ve been working on for the last few months. There were only a handful of business rules to deal with and I thought I could just bang it out.

I know what you’re thinking. You already know where this is headed and you might as well just skip to the end. It’s like in that movie District 9. It started out pretty good with some edgy social commentary but by the end of the movie it just phoned in a cliché Hollywood plot. You know, like “fish out of water”, “buddy movie”, or “trading places” as was the case with District 9.

Anyway, I finished the app and since I only had a few tests I figured I should trace through things a few times to look for obvious problems. After doing that for a few minutes I was ready to press F5 and start working the kinks out. So after hours of zero feedback coding, I took a deep breath and the started the app for the first time.

It promptly bombed out as expected. I worked through a handful of errors and then it was good to go. As I watched it run, I thought to myself that maybe Uncle Bob is wrong about testing and Spolsky isn’t such a douche bag after all. However after processing a couple hundred jobs, it started throwing crazy errors in a tight loop. Crap!

Fast forward a few hours and I’ve got a hunch as to what is causing the problem. The way I wired up the app, I was creating a single NHibernate session for the entire batch of jobs. I knew this could be trouble so I at least made a point to commit after each job and clear the session so it wouldn’t get bogged down with 10K+ entities. I knew the single session was smelly and the errors I was seeing prompted me to refactor.

This is where it got ugly. I needed to do a pretty major overhaul and I was mostly test-less. My blood pressure went way up with each change and the fact that I didn’t have tests just made me take larger steps with no safety net. I felt like a M.A.S.H. surgeon with guts all over the operating table. Part of me thought I should take a few steps back and regroup, but another part of me was reminded of this quote:

If you’re going through hell, keep going. – Winston Churchill

So I stuck with it and got ‘er done, but it wasn’t much fun. What did I take from this experience? No revelations really, just some common sense reinforcement. It’s like rediscovering that diet and exercise is the key to losing weight, except that I rediscovered that not having tests really sucks when you have to make changes.

[TestFixture]

public class MyIntegrationFixture : IntegrationFixture {

    [Test]

    public void Can_add_elements() {

        var repository = Container.Resolve<IRepository<MyEntity>>();

        var entity = repository.FindById(1);

        entity.Add(new Element { Description = "The Description" });

        repository.Save(entity);

        Assert.That(repository.FindById(1).Elements.Count(), Is.EqualTo(1));

    }

}

The problem is the next time I call FindById() I get my object back from the first level cache (ISession), so the Assert passes but looking at the SQL output by NHibernate I can see that no INSERT statement is happening. There are two things that NHibernate needs to do in order for the integration test to work as expected.

1. There needs to be an explicit transaction and it needs to be committed in order to actually send the INSERT statements to the database.
2. The entity needs to be evicted from the session in order to ensure that the next call to FindById() actually goes to the database.

It’s the job of the application to manage the scope of the unit of work. Typically this is per web request in a web app. In a test, it’s per test. This turns into a bunch of boiler-plate noise. Also, this business about evicting the session is an NHibernate specific thing and doesn’t belong in a test that is dealing with an IRepository abstraction.

Since I solve all my problems with a pipeline or decorator, I figured I’d decorate the ISession and commit and evict on the operations I care about:

public class AutoCommitAndEvictSession : SessionDecorator {

    public AutoCommitAndEvictSession(ISession session)

        : base(session) {

    }

    public override object Save(object obj) {

        object result;

        using (var tx = Session.BeginTransaction()) {

            result = Session.Save(obj);

            tx.Commit();

        }

        Session.Evict(obj);

        return result;

    }

    public override void Update(object obj) {

        CommitAndEvict(base.Update, obj);

    }

    public override void SaveOrUpdate(object obj) {

        CommitAndEvict(base.SaveOrUpdate, obj);

    }

    public override void Delete(object obj) {

        CommitAndEvict(base.Delete, obj);

    }

    private void CommitAndEvict(Action<object> action, object entity) {

        using (var tx = Session.BeginTransaction()) {

            action.Invoke(entity);

            tx.Commit();

        }

        Session.Evict(entity);

    }

}

Then I just work it into a test fixture like this:

[TestFixture]

public abstract class IntegrationFixture {

    protected IUnityContainer Container { get; private set; }

    [TestFixtureSetUp]

    public virtual void TestFixtureSetUp() {

        Container = new UnityContainer()

            .AddNewExtension<ConfigureNHibernate>();

    }

    [TestFixtureTearDown]

    public virtual void TestFixtureTearDown() {

        Container.Dispose();

    }

    [SetUp]

    public virtual void SetUp() {

        var session = Container.Resolve<ISessionFactory>().OpenSession();

        Container.RegisterInstance<ISession>(new AutoCommitAndEvictSession(session));

    }

    [TearDown]

    public virtual void TearDown() {

        Container.Resolve<ISession>().Dispose();

    }

}

Before I get into the guts, I would like to provide a little context. My application has 20+ databases scattered across 4 machines.

IRepository<Customer> customerRepository; // customer database on server 1
IRepository<Package>  packageRepository; // customer database on server 1
IRepository<Contact>  contactRepository; // contact database on server 2

The “magic” if you will, happens in the global.asax. I was nosing around in Rhino.Commons for inspiration and adapted a technique I saw there. This is how it looks:

public class GlobalApplication : HttpApplication
{
    private static IUnityContainer container;

    public GlobalApplication()
    {
        BeginRequest += new EventHandler(GlobalApplication_BeginRequest);
        EndRequest += new EventHandler(GlobalApplication_EndRequest);
    }

    protected void Application_Start(object sender, EventArgs e)
    {
        RegisterRoutes(RouteTable.Routes);

        container = new UnityContainer();
        container.AddNewExtension<PolicyInjectorContainerExtension>();
        container.AddNewExtension<HttpRequestLifetimeCoreContainerExtension>();
        container.AddNewExtension<WebMvcContainerExtension>();

        ControllerBuilder.Current.SetControllerFactory(new UnityControllerFactory(container));
    }

    void GlobalApplication_BeginRequest(object sender, EventArgs e)
    {
        var unitOfWork = container.Resolve<IUnitOfWork>();
        unitOfWork.Start();
    }

    void GlobalApplication_EndRequest(object sender, EventArgs e)
    {
        var unitOfWork = container.Resolve<IUnitOfWork>();
        unitOfWork.Commit();
    }
}

I register the UoW with an HttpRequestLifetimeManager so I get a new instance for each request.

Container.RegisterType<IUnitOfWork<ISession>,
	NHibernateUnitOfWork>(new HttpRequestLifetimeManager());

public class NHibernateRepository<T> : IRepository<T>
{
    protected ISession session;

    public NHibernateRepository(IUnitOfWork<ISession> unitOfWork)
    {
        session = unitOfWork.GetContextFor<T>();
    }

    ...

    public virtual void Save(T obj)
    {
        session.Save(obj);
    }
}

Now, this is all the context of an ASP.NET MVC Controller, but I have a similar issue for other (non-web) services. In that context I am using AOP and decorating a particular method with [UnitOfWork], which looks like:

public class UnitOfWorkCallHander : ICallHandler
{
    private IUnitOfWork<ISession> unitOfWork;

    public UnitOfWorkCallHander(IUnitOfWork<ISession> unitOfWork)
    {
        this.unitOfWork = unitOfWork;
    }

    public int Order { get; set; }

    public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
    {
        unitOfWork.Start();

        try
        {
            return getNext()(input, getNext);
        }
        finally
        {
            unitOfWork.Commit();
        }
    }
}

In that context I use a PerThreadLifetimeManager for the NHibernateUnitOfWork, and code ends up looking like:

[UnitOfWork]
public void Process(Job job)
{
    ...
}

You know, there is really no reason why you couldn’t do the same thing in the MVC context. You could basically ditch the global.asax event hooha and just annotate the Controller task:

[UnitOfWork]
public ActionResult ControllerTaskThatRequiresUoW()
{
    ...
}

It’s more explicit than using the global.asax technique and it would allow you to specify different UoW behavior on each controller task:

[UnitOfWork(IsolationLevel.ReadCommitted]
public ActionResult SomeTaskThatShouldNotReadUncommitedData()
{
}

[UnitOfWork(IsolationLevel.ReadUncommitted)]
public ActionResult AnotherTaskWithDifferentRequirements()
{
}

I’d like to try this out next time I get back into ASP.NET MVC, the global.asax event technique felt a little too magical and I don’t think Uncle Bob would approve.