NDI: Unexpected bonus

NDependencyInjection Update:

Now that most of the code-base is using NDI we are really seeing the benefits.

The main bonus I'm getting is with how simple refactoring has become. Once you have the architecture modeling reality, whenever a class needs a service the correct instance is already available in the scope. This means all you need to do is ask for it in the constructor and it all just works. No wiring changes.

When did you last do a "Chicken Run"

"Chicken Run": The process of checking in new code and then leaving before the build has completed, leaving others to deal with the build if it breaks.

Quick svn trick

Here's a one liner to update svn with your local changes.


svn st |awk '/\?/{print "svn add " $2};/\!/{print "svn del " $2}' | sh


Sure there are problems with it... like if the filename has ? or ! in it, then it'll do the wrong thing, but it works for me, so I thought I'd share :)

NDependency Injection: HasCollection Enforces Layered Architecture

I recently added a feature to NDependencyInjection called "HasCollection".

It lets you specify a set of subsystems that all provide the same interface and so can be viewed as a collection.

ISystemDefinition book = new SystemWiring();

book.HasCollection(Page1, Page2, Page2).Provides();

Here Page1, Page2, Page3 are all of type ISubsystemBuilder, which each define the wiring of a specific IPage.

You can only expose something from one of these subsystems if all subsystems implement it. This has the side-effect of enforcing Liskov's Substitution Principle.

At first this feels limiting, but it is leading us to better designs.

Dependency Injection

I have released an early version of a Dependency injection framework I am developing. Yes another one!

NDependencyInjection is being used in a real application and is under heavy development. I intend it to be very opinionated. It will make writing apps the way I write them easy.

First decision: Only support constructor injection.


This decision is not without it's complications. Not least of which is 'what do you do about objects that refer to each-other?'. Luckly I have a solution to this problem. The injection framework in-fact automatically solves these loops.

Second decision: Applications should be built in layers.


When assembling the complex network of simple objects that make up a good design. You group them into sub-assemblies and these into bigger assemblies until you have your final application.

Within the Application there are objects that you only have one instance of. These are by definition Singletons.

Within the sub-assemblies you get classes that act as Singletons, but only within that scope. You may have several instances in your application, but the individual sub-system only has one, and all references to that type refer to the same instance. In all respects this is a ScopedSingleton.

The framework supports Scopes and Singletons.
More on this later.

Anyway.. for now.. you can get at an early release version from NDependencyInjection.