grow your own windsor registration

Recently I have been working on an ASP.NET MVC application that uses Castle WIndsor as the inversion of control container. As I am using dependency injection throughout the code base, it became evident that the growing number of registrations were polluting the MVC application class in the Application_Start() method. bonsai

Fixing this was relatively easy - a designated IocContainer or similar class could isolate all the registrations but this soon began to grow and was violating the open/closed principle - "(classes) should be open for extension, but closed for modification".
Each time I revisited this IocContainer class I was modifying it and adding more registrations. Was there a better way of doing this? How could I make this extensible?

I decided to roll my own Windsor registration framework into the application and I will aim to illustrate how this was achieved in a series of posts that show building it up with test driven development.
I started from scratch with the controller registration process and then moved onto the controller factory before beginning the framework itself.

I'll keep an index of all the Windsor Registration posts here:

  1. windsor controller registration
  2. implementing windsor controller registration
  3. windsor mvc controller factory
  4. revising the windsor mvc controller factory
  5. more windsor mvc controller factory
  6. adding to the windsor mvc controller factory
  7. finshing the windsor mvc controller factory
  8. implementing the windsor controller factory



0 comments: