OB demoted to configurable object factory?

Mar 19, 2008 at 3:04 PM
Edited Mar 20, 2008 at 10:43 AM
I just finished reading the help topic "What is Object Builder?". I was hopping for some clarification on the positioning of OB vs Unity in DI-land. But now I'm even more confused.

I was indeed already puzzled by the statement (everywhere) that OB is not a dependency injection container, but a framework for creating dependency injection containers. Now it seems OB isn't even a framework for DI systems but a configurable object factory!

What's that fundamental something that OB misses and was added to Unity to elevate it to DI container?

Since I can't find anything of that sort I just put my thoughts to a test. I took the StopLight quickstart and in less that two minutes converted it into a working quickstart for OB1. In fact I only had to change 1x assembly reference, 5x using directive and the following lines on Program.cs.

//IUnityContainer container = new UnityContainer()
Builder builder = new Builder(); 
Locator locator = new Locator(); 
locator.Add(typeof(ILifetimeContainer), new LifetimeContainer()); 
 
//    .RegisterType<ILogger, TraceLogger>()
builder.Policies.Set<ITypeMappingPolicy>(new TypeMappingPolicy(typeof(TraceLogger), null), typeof(ILogger), null); 
 
//    .RegisterType<IStoplightTimer, RealTimeTimer>();
builder.Policies.Set<ITypeMappingPolicy>(new TypeMappingPolicy(typeof(RealTimeTimer), null), typeof(IStoplightTimer), null); 
 
//Application.Run(container.Resolve<StoplightForm>());
Application.Run(builder.BuildUp<StoplightForm>(locator, null, null)); 
I think that Unity does a great job at simplifiying OB's interface. It would be even more interesting if it would offer more container functionality, like the one in the Policy Injection Application Block from EntLib. But I feel very unconfortable understating what OB is or can do, just to make Unity look good.

Can some people comment on this? Perhaps I'm missing something important here.
Mar 24, 2008 at 4:35 AM
You have to admit, there's a ton of implementation specific details in the above code snippet. You need to know you need a locator. You need to know how and where to register the lifetime container. You need to know exactly which policies each of the existing strategies use, and how they look them up. And any of that could change if you pick different strategies.

Basically, OB provides mechanism, but not policy. You can configure OB to do just about anything. That's why we call it a framework rather than a container.

Unity builds on top of the mechanism provided by OB, and provides policy - actual, specific ways to do DI. You're trading off flexibility for predictability and ease of use.

If you're familiar with Castle Windsor, I've been saying for quite a while that OB is to Unity what Castle Microkernel is to Castle Windsor; it's a higher level, easier to use facade over a flexible but hard-to-use underlying engine.
Mar 25, 2008 at 1:59 PM
Edited Mar 25, 2008 at 2:03 PM
ctavares wrote:
You need to know you need a locator. You need to know how and where to register the lifetime container.
I don't believe many OB users think twice about that. They just put those two lines there. But you are right: they still need to know they have to. Having OB poorly documented doesn't help much, indeed. But that's a statement about OB's documentation quality not about it capabilities, right?


ctavares wrote:
You need to know exactly which policies each of the existing strategies use ...
Well, you need to know the policy names indeed. You don't need to think (much) about the strategies though.


..., and how they (strategies) look them (policies) up. And any of that could change if you pick different strategies.
I definitely don't think users care at all about how strategies do policy lookups. As said, I believe they don't even think in terms of strategies at all.


Basically, OB provides mechanism, but not policy.

..., and (Unity) provides policy - actual, specific ways to do DI. ...
Perhaps you can expand on what you mean here. I'm might be missing something.


You can configure OB to do just about anything. That's why we call it a framework rather than a container.

Unity builds on top of the mechanism provided by OB ... You're trading off flexibility for predictability and ease of use.

If you're familiar with Castle Windsor, I've been saying for quite a while that OB is to Unity what Castle Microkernel is to Castle Windsor; it's a higher level, easier to use facade over a flexible but hard-to-use underlying engine.
Are you saying Unity is indeed a façade on top of OB? I couldn't agree more. A very clean façade indeed. But you could still just take OB and you wouldn't be missing any DI capability!