Enterprise Library 4: Now with more Peace Love and Rock n’ Roll

At the p&p Summit in November here in Redmond I gave a talk called “EntLib Refactored”. This talk was started by my work done on the EntLib contrib project under the same name. What I wanted to do was make Enterprise Library smaller, simpler and easier to consume. My first attempt was to rewrite the blocks to not depend on Configuration. This was a great first stab, yet I found that what I really wanted was to reduce the size of things (which factoring out config did not do). What I wanted to do was get rid of the factories and use a Dependency Injection Container to wire up the objects. Brad Wilson and myself had been working on Object Builder 2 and Containers on top of them to test it out. What we needed for Enterprise Library was a DI Container.

After working on previous versions of Enterprise Library, we have learned that we needed Dependency Injection (DI) without knowing it and did it at the most basic level. We created factories: which is a form of simple DI. The problem this created is that each individual block was responsible for it’s own configuration and configuration was buried at the bottom of the stack. We need to change around the model a bit to make the responsibility of configuration built into the DI Container and remove all that extra code from each block.

Here is a picture of the old way: [BTW Enterprise Library Factory is buried at the bottom in the Core assembly that no one sees.]

Old Way

Here is the new way:

New Way

This looks better. Configuration is about the container. WAHOOOOOO! This means that building a block, using a block adding your extensions and having the configuration all comes through the container. This will make it easier for you to use Enterprise Library with Unity or your current DI container and allow us to deliver more cool things to you, the customer. Look for more on this later.

That all sounds good, yet there is one lagging thing that needed to be addressed: the devil. Backwards compatibility is the work of the devil, and just like the devil, necessary. This is fueled by the fact that Enterprise Library has reached over a million downloads and not having a story would cause a lot of people to swing large baseball bats at us. So the old way will still work working with factories so you can upgrade and migrate slowly.

Unity is a lightweight container built on top of the work of Object Builder 2, with heavy tweeks by Chris Tavaras. You can read more from Grigori and Chris on Unity.

The funny story about Unity is the name. Grigori and I were trying to come up with a name for this DI block and mentioned it to Peter Provost when we settled on Unity (which is better than the Doohicky Application Block that was up on the board). Peter never thought we would get it pass legal… neener neener is what we said when we got it. He said “Enterprise Library 4: Now with more Peace love and Rock n’ Roll”.

Doesn’t Remind Me from the album “Out Of Exile” by Audioslave

Technorati Tags: , ,

Comments (6)

  1. If you’ve been following Grigori Melnik’s blog , you’ll know a bit about Unity , the new Dependency Injection

  2. If you've been following Grigori Melnik's blog , you'll know a bit about Unity , the new

  3. Windows 2008 and Vista SP1 released to Manufacturing . But it won't be available till March. It seems

  4. derekgreer says:

    Hey Scott.  I can’t wait to see both EntLib4 and Unity.  As you know, the big thing that was always missing with Object Builder was the container.  Sure, you could make your own that instanced the builder, locator, and lifetime container, but it would have been good to have this out of the box.  Well, it sounds like we are going to finally be given a container.

    One concern I have, however, is whether Unity is going to fully expose all of Object Builder’s capabilities.  Looking at the code snippet provided by Grigori, it doesn’t look like it will since I see no methods for registering Strategies and Policies.  Additionally, your team has also been describing it as a "Dependency Injection Container" which is consistent with the code snippet.  I really hope that what your team delivers is a container which allows Object Builder to be used out of the box and not just a container for doing DI.

    This leads to another issue I would like to bring up and that is the terminology that is being used to describe this container and Object Builder.  Object Builder was always advertised as a “Dependency Injection Framework”, meaning that it itself wasn’t a DI container, but was rather a framework for building DI containers.  The framework aspect was a good clarification that needed to be made, but what it was a framework for has always been described incorrectly IMHO.  Object Builder is not merely for dependency injection.  Moreover, it isn’t even limited to Inversion of Control.   The best description of Object Builder is that it is an Object Factory Pipeline Framework.  It can certainly be used for Dependency Injection, but it can also be used for other types of Inversion of Control (like registering events in CAB), or just as a plain ole Factory (which I wouldn’t consider to be true DI or IoC).  If Unity is to be only for DI then this label is certainly valid, but I would like to request that it fully expose the object factory pipeline capabilities of Object Builder …. and that the descriptions of both be broadened to correctly identify what they truly are.  I find it a bit ironic that the name “Dependency Injection” is being used to describe “Inversion of Control” containers given the inception of the name was for the exact opposite reason … too broad a name being given to too narrow a type of IoC.

    – Derek

  5. scottdensmore says:

    Hi Derek,

    The new CTP available on CodePlex allows you to register extensions that will have the ability to add your own custom strategies and policies.

  6. 新技术 says:

      Posted by Robert Bazinet on Apr 10, 2008 09:00 AM The Microsoft patterns & practices group