Deterministic initialization and dependency injection (constructor based)

My demo application I'm working on has a very long startup routine. The application I'm trying to replace with the new ideas log a lot to the console during that (imagine: "now loading data... reticulating splines... login to third party service...").

After spending the whole day learning DI basically from scratch, I create the whole (!) object graph now with a single call to the container. Thank you, e开发者_JAVA技巧verybody here, btw, for providing so many ideas and amazing answers. This community rocks.

But now, what I want to do is to make initialization deterministic again, so I can log in my workflow (I'm using Workflow Foundation 4.0, because I like the declarative style and the fact that I can show people in graphics what happens) when I load data, reticulate splines and all that.

Do you think it would be an acceptable practice to have a "StartupManager" - class (the only singleton in my architecture now, I killed every other "instance getter"!) that will call secondary initialization methods on the objects it got injected (I used buildUp() and property based DI here)?

Reason is that I want to explicitly call the long initialization methods in my workflow activities. Looks amazing in the editor, my boss will be very happy when I present that (he didn't ask for it, it was my idea to spend the weekend doing something, also I think it is a lot of fun).

i assume you're creating your own DI framework for fun and to learn, right? otherwise just use existing one.

no :) you shouldn't have anything static. your algorithm may look like that:

• create instance of your DI builder
• feed that instance with dependencies definition (from file or programatically)
• call your buildUp on that configured builder. this method should return an instance of context
• on the context you call give_me_object_x and you should get an object x filled with all dependencies

or just look how spring is built - it's a very good example of well written DI framework