After publishing my article on ELMAH for ASP.NET MVC the project owner azizatif asked me if I’d like to publish my article on the project wiki as documentation.

After almost two weeks of not getting around to do it, last week I finally found the time to polish the post a bit and post it there.

You can read the article at: http://code.google.com/p/elmah/wiki/MVC

This may be the very first time I blog about a bug in the CLR, but it’s annoying nonetheless.

Apparently a bug in the CLR’s System.Reflection.Emit prevents Rhino.Mocks from working when generic constraints are applied to a method.

void Add<T, TType>()
    where T : class
    where TType : T;

As long as the TType : T constraints is present, all tests will fail with a System.BadImageFormatException.
Now, the bug is known and it looks like it can’t really be helped on the framework side. But, I didn’t want to drop this constraint in my production code just to make the class testable.

So, I went back to the dark ages and actually wrote a Mock class by hand that counted calls to methods, returned preset values for methods.

Overall, the Mock is a mess. There are like 5-6 fields counting all sorts of different stuff just for a simple interface with two methods.

Thank god there are tools like Rhino.Mock that keep me from writing code like that (I really can’t praise Ayende enough for Rhino.Mocks).

Almost a year ago or so I listened to a .NET Rocks episode about the Castle MicroKernel/Windsor and the speaker was saying something along the lines of: “Writing a simple IoC container isn’t all that difficult, it’s basically a hashtable of types and 20 lines of code”.

I always felt that it can’t really be that easy so today I decided to try it for myself. Not so much because I want to use my own container (Windsor does everything I want it to do), but out of curiosity and to learn some things about creating classes with reflection etc.
Also I wanted a small project that I use to improve my TDD and API design skills.

So, here it is. Meet: Pandora

It’s a very lightweight IoC container that is more or less a hashtable of services with their implementing type as value.

[Fact]
public void CanResolveClassWithoutDependencies()
{
    var componentStore = new ComponentStore();
    componentStore.Add<IService, ClassWithNoDependencies>();

    var container = new PandoraContainer(componentStore);
    var result = container.Resolve<IService>();
    Assert.IsType<ClassWithNoDependencies>(result);
}

Pandora will look at the implementing type’s constructor and try to resolve any dependency found there (in a recursive manner). Going from the biggest constructor to the smallest.

One obvious limitation right now is that only one implementing type per service can be provided at the moment.
Also there is no detection of circular dependencies and no lifestyle management (meaning every time I call Resolve I get a new object graph).

Now, this is far away from a useable product. But writing it allowed me to look at some of the problems involved in the process and I had to learn a thing or two about reflection and generics.

One thing I wanted was to avoid having Type parameters. Having to write something like

container.AddComponent(typeof(IService), typeof(Implementor));

feels awkward every time, so I decided to go with generics to enable a syntax like this one:

container.AddComponent<IService, Implementor>();

Much cleaner and I could even add the constraint that Implementor must inherit from IService:

public void AddComponent<T, TImplementor>()
    where T : class
    where TImplementor : T
{
    componentStore.Add<T, TImplementor>();
}

Now, the problem with this is that you can’t convert a Type to a generic call afterwards. Once I needed to resolve dependencies that are of a different type I couldn’t simply write Resolve<myType>().
To invoke a generic method in the current instance with a Type argument you need to use generics to create that method, like this:

MethodInfo method = typeof (PandoraContainer).GetMethod("Resolve");
MethodInfo generic = method.MakeGenericMethod(myType);
generic.Invoke(this, null)

So, it works but I guess it’s not the best way to regularly use reflection to call methods, so I went back to Type parameters and created overloads for the generics. (And now I see why Windsor has Type parameter overloads for everything ;))

Pandora is open source and licensed under the Apache License 2.0. I strongly suggest you do not use this anywhere near production systems but strictly for educational purposes.

During the last few months I have been the technical architect behind the development of a new platform for tourism in Carinthia. While I have already discussed some of the inner workings of the project during that time, I thought it might be interesting to let you in on a deeper look at the application architecture behind the site: www.kaernten.at.

Quick facts:

The site is built using ASP.NET MVC (since Beta 3) being hosted by IIS6 on a MSSQL 2005 database.

The whole thing is glued together by Castle Windsor and DynamicProxy2 while tests are all run through xUnit and Rhino.Mocks. The error reporting is done through ELMAH.

General Architecture

There are three layers to the application:

The Web tier was the actual ASP.NET MVC Site and this was the part I was least involved in. The Controllers use the Services layer to retrieve relevant information and then passes it on to the View.

I knew from previous projects that the web tier is the first place that is going to get torn apart by weird customer requests and other very ui-driven changes, so the general goal of the services layer wasn’t only to present data to the web, but to provide services to manipulate that data for presentation. So the Services layer is mostly  about filtering/sorting/querying data from the database, since there is no common logic to the madness of presentation requirements.

The database tier is actually split across two tiers, the Sql tier and the Proxy tier. (I’ll cover the Proxy in a future post in more detail.) Most notable the whole database retrieval is done through Linq to  Sql.

Also everything in the system is dependency injected, there is not one call to new() anywhere in the system, except for the construction of data objects (that in my design aren’t allowed to have services on them).

Query logic

The whole site is based on the concept of When youre visiting? What are you interested in? And Where would that be?

So, there is not a typical tree of categories with articles to browse through, but rather is the whole content of the site the result of all articles that match your criteria. Therefore every article in the system has a list of tags it’s connected to (when  and what both are just tags).

Now, one of the main challenges for all of the team (involving the customer) was to really define that query logic, and we changed it about 10 times during development, and I’m sure it will change even more in the future.

So, although it might have been possible to do all querying/sorting/filtering with Sql, the Sql code became utterly unreadable and sometimes involved n subselects.
I gave up on the Sql pretty early on since it was just too un-maintainable and felt too restraining.
My solution to this was to load all articles into memory and filter/sort them from there. This then enabled me to easily implement queries like this one:
All articles that are tagged a,b,c AND at least one of d,e,f (or more formally: (a && b && c) && (d || e || f))

And that’s about it for the general picture right now. I’m planning on posting more on the technology behind www.kaernten.at over the next couple of days.

In my last post on the technology behind www.kaernten.at, I concluded with the fairly bold statement that all objects are kept in memory to ease querying.

That’s not really true, but also not really false.
When the article list is loaded initially, only a slim index of all articles is retrieved from the database. All information relevant to querying and sorting (id, tags, publication date, visibility) gets fetched at once. I used Castle DynamicProxy2 to create proxy objects that pose a the real thing to lazy load the article data on access. So although there may be 10.000 articles currently in memory, only those that have really been viewed by a user have been fully loaded, while all query criteria are present in memory.

But lazy loading wouldn’t work if the list of proxy objects wouldn’t get cached somewhere, and that’s what I wanted to go over in this post. All articles retrieved (in their proxied form) come from the generic IRepository<T> interface that only has one method: GetAll(). I wanted to avoid having the caching be tied into the Repository at all costs since it would make my life hell when testing the repository itself. So I decided that the best course of action would be to create a decorator that took care of the caching, separating caching from the Repository implementation (and it’s also really easy if there is only one method to implement):

Switching caching on or off is now as simple as removing/adding one line to the Windsor configuration. And the caching code is shared among all Repository implementations, for any type of IArticleRepository<T>.
If it needs to get cleared I can simply ask the Windsor container to retrieve all ICache implementing classes (they are singletons) and call ICache.Clear() on them.

Now, the most interesting thing here is that the cache is asynchronous. If it gets cleared, a background worker process gets spawned on the PopulateCache() method, generating the updated data from the system, while subsequent requests to the Repository (while it’s being populated) still return the outdated list of data. Once the background worker is done populating, it simply swaps out the references and the old data gets collected by the garbage collector.
This result in some pretty sweet response times, since except for the very first startup of the system, every request is served directly from memory, without any data fetching at all.

This part was also crucial to the whole thing since fetching the data is a rather long running and cpu heavy task, taking up to 60 seconds while testing it against 10.000 articles (with a debugger attached on my laptop).
Initially I tried to speed the querying and object building up to allow for a synchronous cache refill, but although I did some optimizations (like not using some LinQ methods) the attempt to reduce the execution time to something acceptable was futile.

Right now the cache is implemented by just a simple List<T> that stores everything the repository returned, but if need arises it can easily be changed to use memcached or some other more sophisticated caching method.