Cyclic Dependencies?

Topics: CodePlexContainer, ObjectBuilder
Sep 7, 2007 at 2:46 AM
I'd like to be able to create a set of objects at once. If I don't mark them as singletons, then I get a blown stack. If I mark them as singletons, well, they aren't. So, if I have a Foo that has a Bar parameter in its constructor, and the Bar takes a Foo in its constructor, I'd like to have the Foo and the Bar point to each other when I ask for a Foo, and next time I ask for a Foo, I want a different Foo and a different Bar (that point to each other).

I was thinking that I could create a new container and make them singletons, but I have the situation where the Foo needs a Baz, which is a "global" singleton. It looks like if I create a child container, but the Baz isn't created yet, it will get created in the child's locator, not the inner locator... (I haven't actually run it).

Any ideas?

Sep 7, 2007 at 1:57 PM
Are you using ObjectBuilder directly, or one of the containers? If you're using OB directly, which version are you using?
Sep 7, 2007 at 6:13 PM
Aha. Yes I see now. I'm looking in the Samples directory. The CodePlexContainer doesn't allow you to specify a singleton type, only register a singleton instance, which of course goes in the correct locator. While the DependencyContainer solution allows you to configure singleton creation strategies, but doesn't allow you to have nested containers!

What's needed is a singleton strategy that is tied to the container, such that when it creates a singleton, it creates it at the correct location. And that means you have to traverse the hierarchy twice to give singeltons a chance to run before default rules in the leaf kicks in... Aiii. Am I on the right track?

I've written my own container for production code and we're using the Jan 16 build (I wasn't sure of the license for the DependencyContainer sample that was linked). Maybe I'll have a go at writing a new container.
Sep 7, 2007 at 9:47 PM
The reason I ask which version of ObjectBuilder you're using is because OB 1.0 (build 51205 or 51206) supports cyclic dependencies, with some very stern limitations (all you can do with the object instance you get during injection is store it, not call it, because it might not be initialized yet). There were other issues besides this one (including a blocking bug with this system which prevented method interception from working), so we had to get rid of it.

In general, I'd suggest that you're going to be much happier breaking the cycle anyway.
Sep 7, 2007 at 9:47 PM
Also, all the code in the project, including the samples, is covered by the license found here: