Speaking about DI/IoC, Microsoft Patterns & Practices has just released an MSPL licensed DI container in the project Unity. I must say, I’m disappointed.
Here’s a list of things I think Unity did wrong.
- It’s a P&P project, and not part of the BCL. I’m not sure we need a full DI container in the BCL, but I do believe a lot of the interfaces should be there.
- They call this a "lightweight" container, but it contains two assemblies. Doesn’t sound too light weight to me. I haven’t fully looked into this yet, and it’s possible one of the assemblies provides optional features layered on a basic container, in which case I’d have to retract what I just said in this point ;).
- The interfaces are designed incorrectly. There’s basically one interface, IUnityContainer, that’s the driving interface. Like mentioned, I’d prefer this in the BCL, with a more generic name, such as IObjectContainer. Further, this should be split into two interfaces: the APIs to resolve instances should be separated from the APIs to configure a container, such as is done with IServiceProvider and IContainer in the BCL.
- Types are resolved through reflection. At the basic level the container should be operating on "factory delegates" registered with the container. This is the most flexible design, and also provides the best performance. The reflective stuff can be built on top of this. I’d layer it, so if you don’t need it you don’t have to include it, but I wouldn’t argue to strongly if the container (and interfaces) provided both out of the box. The fact that the factory delegate isn’t present in the API at all, though, is a mistake. Just as an example, this container doesn’t provide support for per-thread scope, you only have Singleton (in two varieties… one where the user creates the instance and one where the container creates the instance) and per-call. There’s absolutely no way to change this, short of changing the container implementation. If we had delegate factory registration, you wouldn’t have this problem.
- There’s still a lot of complexity here. I want a lighter weight solution.
Over all, it’s not a bad library, but it doesn’t deliver what I believe we need.