Christian Edward Gruber wrote:
On 20-Apr-09, at 19:39 , Thiago H. de Paula Figueiredo wrote:
I think he means value objects or domain models. You can't usefully
have the container create an instance of Movie because movie is a
data-carrying node. It's a bit like having the IoC container create
any random Map you might need. If it's a named Map that is a
central store for something, then sure, but if I'm creating a Map of
values to be used elsewhere that has limited life-span and/or will
be populated from the database then re-generated in another user
session - these are examples of things you wouldn't put into the
container.
Now I get it. Thanks Christian!
All you said, to me, is one more reason to not inject services in
domain objects . . . :)
Yeah - that's such an anti-pattern. If you're injecting things into
value objects, you've probably not separated concerns well.
OK, some motivation to my approach:
Looking to DomainDrivenDesign I am putting behaviour to the
domain-objects. Internally I base this behaviour on interfaces, so I
decouple things.
Because I use dependency injection for my domain-object, why shouldn't I
use a dependency injection container like tapestry-ioc then? I try to
avoid coding these annoying factories myself.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
