A question on IoC/DI theory

[Todor Boev]

Hello,
I am a long time observer of IoC/DI containers but sadly have not had a
chance to use them for a real project yet :( Therefore my views on the
matter are probably immature. I believe DI should permeate the program
in depth rather than be used only for the first few long-lived
components. I would like to use the DI container as a replacement of
good'ol new. So DI should be about scope management. Like in the
classical http example where components live in
"server"->"connection"->"request" scope and each scope creates and
destroys multiple instance of the next scope. However this means that at
least one object in the older scope must use the container API to
create->populate->start->stop->destroy the next scope. Isn't this at
odds with the number one DI principle of keeping components independent?
Is there some popular practice to deal with this or I should just accept
that the coast of DI everywhere is some dependence on the container API?

Cheers,
Todor

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jörg Schaible]

Hi Todor,

Post by Todor Boev
Hello,
I am a long time observer of IoC/DI containers but sadly have not had a
chance to use them for a real project yet :( Therefore my views on the
matter are probably immature. I believe DI should permeate the program
in depth rather than be used only for the first few long-lived
components. I would like to use the DI container as a replacement of
good'ol new. So DI should be about scope management. Like in the
classical http example where components live in
"server"->"connection"->"request" scope and each scope creates and
destroys multiple instance of the next scope. However this means that at
least one object in the older scope must use the container API to
create->populate->start->stop->destroy the next scope. Isn't this at
odds with the number one DI principle of keeping components independent?
Is there some popular practice to deal with this or I should just accept
that the coast of DI everywhere is some dependence on the container API?

You will normally create some kind of service component that hides the
container. Simply model an interface like

interface ServiceManager {
RequestId startRequest(...);
void stopRequest(RequestId id);
}

The concrete implementation of this interface may setup any kind of
container hierarchy. In a standalone app it would even contain the main
method, create an instance of itself and add it to the root container. That
way this class contains the only code that actually references something in
Pico (unless you're using custom lifecycle interfaces).

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Witold Szczerba]

I see it this way: when writing application, one should write its
components the way they are totally unaware of IoC/DI container (and,
where it is possible, of each other). This should be like 95% of your
code (including unit tests). Then you have a very thin layer which
does use IoC container to wire everything up (IoC container is,
however, not necessary, but helpful). Sometimes that 5% can grow, but
the whole idea is to keep application clean, to be able to reuse
components in other applications, just not to make one huge spaghetti.

Regards,
Witold Szczerba

Post by Todor Boev
Hello,
I am a long time observer of IoC/DI containers but sadly have not had a
chance to use them for a real project yet :( Therefore my views on the
matter are probably immature. I believe DI should permeate the program in
depth rather than be used only for the first few long-lived components. I
would like to use the DI container as a replacement of good'ol new. So DI
should be about scope management. Like in the classical http example where
components live in "server"->"connection"->"request" scope and each scope
creates and destroys multiple instance of the next scope. However this means
that at least one object in the older scope must use the container API to
create->populate->start->stop->destroy the next scope. Isn't this at odds
with the number one DI principle of keeping components independent? Is there
some popular practice to deal with this or I should just accept that the
coast of DI everywhere is some dependence on the container API?
Cheers,
Todor
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email