Essence Pattern in C#

I regularly use Dependency Injection in my dev projects. I use it because it makes it easier to isolate components when unit testing and I use it because it's neat. In the course of setting up DI I go back and forth on which injection approach to use. Not, what DI framework to use. That's a different question. For the record, I use Ninject. Your preference may be different. Anyway, the issue for me is deciding whether to use "constructor" or "property" based injection.

Property injection uses convention, or if you're using C# or similar language Attributes, which get set by your IoC container (Kernel if you're using Ninject). The Pros: You get to preserve your default constructor and it's easy to add properties to a class without breaking existing references to your constructor. The Cons: it's not as immediately clear what is required by your class. Also, attributes are like salt. It should be used sparingly. Over attribution of an class starts to obscure its actual purpose, kind of like salt.

With constructor based injection, all your dependencies are listed as constructor parameters. The Pros: it's easy to determine just from looking at the constructor what is required and it's impossible to instantiate your class without them. The Cons: you don't get a default constructor which is kind of nice if you're using other frameworks that require them. Also, if you have a lot of dependencies, your parameter list if going to get pretty long.

So, that got me to thinking, "how many parameters is too many?" There isn't a right answer necessarily, as with many things in programming. But, I've decided I have an opinion. Three. Three is the number I find acceptable. Any more than three and I start to wonder if I'm doing something wrong. Any more than three and it looks ugly to me. Some people say humans are capable of keeping up to seven (7) things in their head at once. But, I'd rather save the other four (4) for local variables inside my method. Anyway I think three is good. With three your intent should still remain clear and the majority of methods should make do with one or two. In fact, two is better. Once is best. But three. Sure. I can deal with three.

I searched around for other opinions. Naturally, as with all things in programming, there are many opinions. Here is a useful discussion with a minimal amount of vitriol.

How many constructor arguments is too many?

In reading this discussion I was reacquainted with an old design pattern than I'd read about years ago but never really considered implementing in any of my projects. This time I was intrigued enough to give it a go. Between my burning question about parameters and their appropriate quantities and the need to see what kind of spin I could put on this pattern using modern C# (4.0 as of this writing), I wrote some code of my own. I implemented an Essence pattern using Builder and just a touch of Fluent Interface. I'm not normally a huge fan of method chaining, but in cases where I'm expression state or configuration in code I think it can work. Anyway here it is.

EssencePattern.zip