January 8. 2008 21:32

Let me see if I can try answer that.

1/ Awkward extensibility model
2/ You need extensive amounts of code to make it useful
3/ Configuration is a PITA
4/ It is too complex for the job
5/ It ships with very heavy weight containers that taints the code that is using them with knowledge of the container.
6/ It is awkward to deal with on a day to day basis.
7/ It uses Reflection all over the place, without regards to what it is going to do to the application.

It just takes too much work to deal with it.

Ayende Rahien

January 27. 2008 05:23

I actually like the OB. The things I don't like about it are

1) Lack of Docs and samples

2) Very powerful and very complex, too complex to gain a complete understanding and use in projects with total confidence. I always think that there are things that I still don't get about it.

3) Complex configuration model.

Those are my problems with it. But I do think it is most powerful DI framework out there especially given its capability to apply filters to control object creation.

Thank You,
Vish

Vish

February 12. 2008 17:48

It is really good Di-section of Object Builder. I had been doing a similar activity with a approach of Design principle discovery and use in mind.You can find code and presentation on blog.

http://burhansaadi.spaces.live.com
or
www.sadilabs.com/.../...Object-Builder-Part-1.aspx

burhan

February 17. 2008 01:35

Chris,

I started using Object Builder directly a few years ago to port the CAB's event brokering capabilities to a stand alone component for use within a Web client framework I designed. It was my first exposure to the world of "Inversion of Control" and "Dependency Injection".

I must be one of the few who really appreciated the design. While it certainly has its complexities, the overall approach of a strategy pipeline with policies just clicked with me. I personally felt the API was intuitive. That said, I think I got it and appreciated it because I understood what it was from the onset.

I think the problem people have had with Object Builder is that they have always tried to compare it to the existing containers available at the time. Other containers used an XML approach, but where was Object Builder's XML support? Other containers were easier to use out of the box, but Object Builder had all of these pieces you had to understand and put together first to get it do do any thing (speaking of the lifetime container, locator, and builder). The problem really comes down to the fact that they weren't comparing apples to apples. Object Builder is for building the things they were trying to compare it to, it wasn't a container in-and-of itself.

Bottom line, they just didn't understand the concept that it was a framework, not a container.

I think Unity will really be the first thing that can rightfully be compared to products such as Windsor, Spring, and Structure Map. Unfortunately, you will have to contend with the baggage that being Microsoft brings.

It's funny that certain people are so quick to jump on Microsoft with claims of "reinventing the wheel", but seem to give a free pass when non-Microsoft OSS projects offer new alternatives.

<a href="ayende.com/.../a> we read:

"I would really like to know, why the hell do we need another duplication of OSS?"

But <a href="www.ayende.com/.../a> we read:

"I don't see an issue here. The OSS community isn't a well coordinated place by defination. Each of the above solve its developers problems best, as a user of those projects, all you need is to decide what you want to do with those."

Draw your own conclusions about the level of objectivity here.


Oh yeah, and Object Builder is an "Object Factory Pipeline Framework", not a "Dependency Injection Framework"

Derek Greer