We’ve just pushed out version 2.0 of our open-source, component composition framework. This is the framework we use internally day-in, day-out for our dependency injection. The previous version had a dependency on Castle Windsor, but in this new version we have implemented our own container.
There are a few reasons we decided to take this step. Mainly, we were developing some early Windows Phone 8 and Windows 8 applications last year, like our cross-platform charting controls and Milliman’s Azure Compute Dashboard, and we couldn’t live without DI. At the time, none of the existing container frameworks supported all the main Microsoft platforms that we were working with, so we had to “roll our own”. I did attempt to build a Windows 8 Azure Dashboard app (see pic) without DI to begin with, but the barrier to maintainability meant when it got large enough I ended up pretty much going back to the start and reimplementing it using our new framework.
Other containers are also really expensive for a ‘miss’ scenario (i.e. trying to resolve a component that isn’t registered in the container), because they use exceptions to implement this. We wanted to be really efficient for failing to find a match so we could implement an inexpensive “fallback mechanism” (e.g. looking in the container for handlers for specific content types, falling back to more general versions, if they were not found).
The other reason was, as much as we love Castle Windsor, it does a lot (much like the Spring Framework in the Java ecosystem). It suffers from a problem that many OSS projects do – it’s based on contributions from the community but rarely do people rationalise and prune the feature set. So with our container, we’ve stripped it back and included only the features we require. This means that there’s lots it doesn’t do, but in this series of blog posts, we’re going to cover many of the main usage scenarios.
Whatever the framework, component composition works the same way: you have contracts and concrete implementations and you need to map one against the other. The Endjin Composition Framework helps you work smarter, not harder by making component composition simple.
You can install the packages via NuGet or the source code is available up on the endjin GitHub page. There are packages for use with .NET 4.0, .NET 4.5, WinRT and Windows Phone 8 frameworks. Additionally there is an Endjin.Core.Composition.Web package with extensions for use in ASP.NET MVC 4 / WebAPI applications.
There are samples in the GitHub repo for how to use component composition for each of the supported frameworks, and in the next post I’ll go over how to get set up.