Krzysztof Koźmic's blog

Good bat­tery of tests is like good wine. You will not under­stand its value until you’ve expe­ri­enced it. There’s few things as lib­er­at­ing in soft­ware devel­op­ment as know­ing you can refac­tor fear­lessly hav­ing con­fi­dence your tests will catch any break­ing changes.

I don’t have the time not to write tests

I can’t imag­ine work­ing on Wind­sor if it wasn’t thor­oughly cov­ered by tests. On the other hand, most of the prob­lems I’ve faced on var­i­ous other projects, could have been avoided had they been bet­ter tested. Prob­lem is – they were. Most of the projects I’ve been work­ing on had tests and if you’d inspect code cov­er­age of those tests it would usu­ally yield a rea­son­ably high num­ber. Except code cov­er­age doesn’t tell the full story. What’s impor­tant is not just that the code is tested. And that’s because not all code is equal.

public class Event : EntityBase
{
	public Event(string title, string @where, DateTime when, string description, UserInfo generatedBy)
	{
		Title = title;
		Where = @where;
		When = when;
		Description = description;
		GeneratedBy = generatedBy;
	}

	public virtual string Title { get; set; }

	public virtual string Where { get; set; }

	public virtual DateTime When { get; set; }

	public virtual string Description { get; set; }

	public virtual UserInfo GeneratedBy { get; set; }
}

The code as above will have dif­fer­ent test­ing require­ments from your price cal­cu­lat­ing logic if you’re writ­ing an e-commerce appli­ca­tion. The higher cyclo­matic com­plex­ity and the more crit­i­cal the code is the more atten­tion it requires when test­ing. That’s pretty easy to com­pre­hend and agree with.

There’s another angle to it, which is often over­looked. Indeed, like in the tale of boiled frog, that’s the rea­son why the qual­ity of our tests dete­ri­o­rates – the why of a test. Why and when to write a test is equally impor­tant as what to test. And the answer here is quite sim­ple. So sim­ple in fact, that often over­looked or neglected. When­ever some­thing in the code changes the change ought to be doc­u­mented in test. When­ever your code changes it is most vul­ner­a­ble. And isn’t it he premise of Agile? To embrace the change?

It is not enough to test your new code. If a change to some code is made and no test was changed or added that should raise a red flag for you – I cer­tainly am going to make that a rule for myself – any change to a non-trivial code must be accom­pa­nied by a change in exist­ing tests, and (almost always) by addi­tion of new tests.

Quite reg­u­larly I get asked by peo­ple how they should use IoC con­tainer in their appli­ca­tion. I don’t think I can answer this ques­tion once and uni­ver­sally because every appli­ca­tion is dif­fer­ent, every appli­ca­tion has dif­fer­ent needs and every appli­ca­tion has dif­fer­ent oppor­tu­ni­ties for lever­ag­ing an Inver­sion of Con­trol container.

How­ever there are some gen­eral rules and pat­terns that I use and I thought I will blog about this instead.

While I use a con­crete exam­ple of Cas­tle Wind­sor, the dis­cus­sion here is universal.It applies to all containers.

Inver­sion of Con­trol means con­tainer does not exist

Basic dif­fer­ence between an Inver­sion of Con­trol frame­work and any other kind of frame­work is that the con­trol gets inverted. Your appli­ca­tion does not call to the frame­work. Instead the frame­work is aware of your appli­ca­tion and it goes and does its stuff with your application’s objects.

Since Inver­sion of Con­trol Con­tain­ers are Inver­sion of Con­trol frame­works that par­a­digm applies to them as well. They con­trol objects in your appli­ca­tion. They instan­ti­ate them, man­age their life­cy­cle, invoke meth­ods on them, mod­ify them, con­fig­ure them, dec­o­rate them, do all sorts of stuff with them. The main point here is – the appli­ca­tion is com­pletely unaware of that. I feel tempted to put another Matrix anal­ogy here, but hope­fully you get the point with­out it.

The most vis­i­ble man­i­fes­ta­tion of this fact, which clearly illus­trates the lack of any knowl­edge about the con­tainer is that I tend not to ref­er­ence the con­tainer in the appli­ca­tion at all. The only place where the ref­er­ence to the con­tainer does appear is the root project which only runs the appli­ca­tion. It how­ever con­tains no appli­ca­tion logic and serves merely as appli­ca­tion entry point and con­tainer bootstrapper.

Not ref­er­enc­ing the con­tainer at all serves a few pur­poses. Most impor­tantly it helps to enforce good OOP design, and blocks the temp­ta­tion to take short­cuts and use the con­tainer as Ser­vice Loca­tor.

Three calls pat­tern of usage

Now, prob­a­bly the most inter­est­ing part is this sim­ple boot­strap­per. How do I inter­act with the container?

I tend to use pat­tern of three calls to the con­tainer. Yes you heard it right – I only call the con­tainer is three places in the entire appli­ca­tion* (con­di­tions apply, but I’ll dis­cuss this below in just a moment).

My entire inter­ac­tion with the con­tainer usu­ally looks like this:

   1: var container = BootstrapContainer();

   2:  

   3: var finder = container.Resolve<IDuplicateFinder>();

   4: var processor = container.Resolve<IArgumentsParser>();

   5: Execute( args, processor, finder );

   6:  

   7: container.Dispose();

The three steps are:

1. Boot­strap the container
2. Resolve root components
3. Dis­pose the container

Let’s go over them in turn:

One Install to rule them all…

Boot­strap­ping is incred­i­bly simple:

   1: private IWindsorContainer BootstrapContainer()

   2: {

   3:     return new WindsorContainer()

   4:         .Install( FromAssembly.This() );

   5: }

The most impor­tant rule here (which is impor­tant in Wind­sor, but good to fol­low with other con­tain­ers that enable this)  is – to call Install just once and reg­is­ter and con­fig­ure all the com­po­nents dur­ing this sin­gle call. Also impor­tant stuff is to use the Install method and Installers to encap­su­late and par­ti­tion reg­is­tra­tion and con­fig­u­ra­tion logic. Most other con­tain­ers have that capa­bil­ity as well. Aut­o­fac and Nin­ject call it mod­ules, Struc­tureMap calls it registries.

As you can see on the screen­shot above I usu­ally have a ded­i­cated folder called Installers in my boot­strap assem­bly where I keep all my installers. I tend to par­ti­tion the installers so that each one of them installs some cohe­sive and small set of ser­vices. So I might have View­Mod­elsIn­staller, Con­trollers Installer, Back­ground­Ser­vicesIn­staller, Log­gin­gIn­staller etc. Each installer is sim­ple and most of them look sim­i­lar to this:

   1: public class ArgumentInterpretersInstaller : IWindsorInstaller

   2: {

   3:     public void Install(IWindsorContainer container, IConfigurationStore store)

   4:     {

   5:         container.Kernel.Resolver.AddSubResolver(new ArrayResolver(container.Kernel));

   6:         container.Register(

   7:             Component.For<IArgumentsParser>()

   8:                 .ImplementedBy<ArgumentsParser>().LifeStyle.Transient,

   9:             Component.For<IParseHelper>().ImplementedBy<ParseHelper>(),

  10:             AllTypes.FromAssemblyContaining<IArgumentInterpreter>()

  11:                 .BasedOn<IArgumentInterpreter>()

  12:                 .WithService.Base());

  13:     }

  14: }

This par­ti­tion­ing helps keep things tidy, and by lever­ag­ing Installers you end up writ­ing less code, as now Wind­sor will autodis­cover them and reg­is­ter in just a sin­gle call to FromAssembly.This(). Also another note­wor­thy fact about this, is that you lever­age Inver­sion of Con­trol prin­ci­ple to con­fig­ure the con­tainer itself. Instead of pass­ing the con­tainer around, which should always raise a read flag, you’re telling Wind­sor – con­fig­ure your­self. Nice and tidy.

Another impor­tant thing to notice, is that I tend to lever­age con­ven­tion based reg­is­tra­tion, rather than reg­is­ter­ing all the com­po­nents one by one. This greatly cuts down the size of your reg­is­tra­tion code. It takes the bur­den of reg­is­ter­ing each newly added com­po­nents man­u­ally off of your shoul­ders. It also enforces con­sis­tency in your code, because if you’re not con­sis­tent your com­po­nents won’t get registered.

* yes – I do inter­act with the con­tainer in the installers, so I clearly break the three calls rule, right? No – I inter­act with the con­tainer in objects that extend, or mod­ify the con­tainer itself – in this case it’s obvi­ously not a bad thing.

…and in one Resolve bind them

Sim­i­lar to unit tests prin­ci­ple – one log­i­cal assert per tests, I fol­low the rule of allow­ing explicit call to resolve in just one place in the entire appli­ca­tion. Usu­ally this will be just one call, that pulls the root com­po­nent (Con­troller in MVC appli­ca­tion, Shell in WPF appli­ca­tion, or what­ever the root object in your app is). In the exam­ple above I have two root objects so I have two calls to Resolve. That’s usu­ally OK. How­ever if you have more than three, you might want to take a closer look at rea­sons for that, as it’s quite unlikely you really need this.

The impor­tant thing is to have the Resolve calls in just this one sin­gle place and nowhere else in your appli­ca­tion. Why that’s impor­tant? To fully lever­age container’s poten­tial, instead of telling it at every step what it should do. Let it spread its wings.

Clean up

It is impor­tant to let the con­tainer clean up after itself, when its done doing its job. In this case I can not only say that this is some­thing I do. You also always should dis­pose your con­tainer at the end of your appli­ca­tion. Always, no excep­tions. This will let the con­tainer to shut­down grace­fully, decom­mis­sion all the com­po­nents, give them chance to clean up after them­selves, and free all the resources they may occupy.

What about you? How do you use your container?