You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by manuel aldana <al...@gmx.de> on 2009/04/20 21:38:51 UTC

[tap-ioc] point of injection

When does tapestry-ioc inject stuff to object (@Inject annotation)? I 
guess it is straight after finishing the constructor...

Is it possible to have the injection already available after the call of 
super() inside the constructor? This way the injection would be 
available already inside the rest of the constructor code.

class Foo{
 @Inject
 Service service
 
 Foo(){
  //service is null in constructor
  ....
 }
}

-- 
 manuel aldana
 aldana@gmx.de
 software-engineering blog: http://www.aldana-online.de


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [tap-ioc] point of injection

Posted by manuel aldana <al...@gmx.de>.
Thiago H. de Paula Figueiredo wrote:
>
>> If applicable I try to inject services to domain-objects to add 
>> pluggable behaviour to them (so I don't end up with an anemic domain 
>> model).
>
> I disagree with adding services to domain objects. But please let's 
> not start a discussion about it. This is not the right place.
OK, maybe there is a misunderstanding about the term service here. I 
want to inject just an implementation of an interface and reuse tap-ioc 
factory facilities for that.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [tap-ioc] point of injection

Posted by Christian Edward Gruber <ch...@gmail.com>.
On 21-Apr-09, at 07:02 , manuel aldana wrote:
> Christian Edward Gruber wrote:
>> On 20-Apr-09, at 19:39 , Thiago H. de Paula Figueiredo wrote:
>>>
>>> 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.


Ok, I think there are two different kinds of logic here - pure  
business logic, and plumbing.  I don't think people are opposed to  
putting pure domain logic or business logic into domain objects - but  
these aren't things that would usually need factories.  What you  
shouldn't be putting into domain objects is plumbing, so to speak.  So  
maybe you're just wrapping up domain logic into components and  
injecting them - I guess that's all-right, but I typically don't see  
that sort of logic as separate from the domain objects, and wouldn't  
probably make inject-able components out of it in the first place.   
But anyway, as Thiago said, we should take this off-list, since it  
isn't a general architecture discussion list.

Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [tap-ioc] point of injection

Posted by manuel aldana <al...@gmx.de>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [tap-ioc] point of injection

Posted by Christian Edward Gruber <ch...@gmail.com>.
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.

Christian.

Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [tap-ioc] point of injection

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 20 Apr 2009 20:26:17 -0300, Christian Edward Gruber  
<ch...@gmail.com> escreveu:

> 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 . . . :)

> But, you might put the thing that creates them into the container as a  
> service.

That's the bet advice to Manuel I can think of.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [tap-ioc] point of injection

Posted by Christian Edward Gruber <ch...@gmail.com>.
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.  But, you  
might put the thing that creates them into the container as a service.

For example, if you have DAOs to persist and look-up "Movie" and  
"Person" where Person is assigned to various roles (screenwriter,  
actor, director), then that DAO may also have creation methods to give  
you new instances of such domain objects.  Though for that sort of  
thing, most persistence frameworks allow you to persist pojos, so the  
value of doing this may be suspect.

Christian.

On 20-Apr-09, at 19:06 , Thiago H. de Paula Figueiredo wrote:

>> An example could be for instance domain-model objects, which use  
>> services internally. You create them by for instance passing  
>> mandatory fields into the constructor.
>
> I don't get this example.

Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [tap-ioc] point of injection

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 20 Apr 2009 19:05:24 -0300, manuel aldana <al...@gmx.de> escreveu:

> Your convention makes sense, but what do you do with objects which are  
> usually created directly by other code and not by tapestry, thus  
> constructor injection won't be the best solution?

If it's possible, I add the object as a Tapestry-IoC service. Create  
everything through a factory is a good practice, and T-IoC does that very  
nicely.

> An example could be for instance domain-model objects, which use  
> services internally. You create them by for instance passing mandatory  
> fields into the constructor.

I don't get this example.

> If applicable I try to inject services to domain-objects to add  
> pluggable behaviour to them (so I don't end up with an anemic domain  
> model).

I disagree with adding services to domain objects. But please let's not  
start a discussion about it. This is not the right place.

> So I am right that tapestry-ioc exclusively is injecting fields after  
> having passed the constructor code?

I don't know, but I guess the answer is yes, as it's impossbile in Java to  
invoke any method in an object before a constructor call on it.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [tap-ioc] point of injection

Posted by manuel aldana <al...@gmx.de>.
Thiago H. de Paula Figueiredo schrieb:
> Em Mon, 20 Apr 2009 16:38:51 -0300, manuel aldana <al...@gmx.de> 
> escreveu:
>
>> When does tapestry-ioc inject stuff to object (@Inject annotation)? I 
>> guess it is straight after finishing the constructor...
>>
>> Is it possible to have the injection already available after the call 
>> of super() inside the constructor? This way the injection would be 
>> available already inside the rest of the constructor code.
>
> Wouldn't it be easier to just use constructor injection? I use @Inject 
> just in Tapestry pages, components and mixins, never in services. In 
> them, always constructor injection. It makes it way easier to test 
> them without Tapestry-IoC.
Your convention makes sense, but what do you do with objects which are 
usually created directly by other code and not by tapestry, thus 
constructor injection won't be the best solution? An example could be 
for instance domain-model objects, which use services internally. You 
create them by for instance passing mandatory fields into the constructor.

If applicable I try to inject services to domain-objects to add 
pluggable behaviour to them (so I don't end up with an anemic domain model).

So I am right that tapestry-ioc exclusively is injecting fields after 
having passed the constructor code?

-- 
 manuel aldana
 aldana@gmx.de
 software-engineering blog: http://www.aldana-online.de


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [tap-ioc] point of injection

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 20 Apr 2009 16:38:51 -0300, manuel aldana <al...@gmx.de> escreveu:

> When does tapestry-ioc inject stuff to object (@Inject annotation)? I  
> guess it is straight after finishing the constructor...
>
> Is it possible to have the injection already available after the call of  
> super() inside the constructor? This way the injection would be  
> available already inside the rest of the constructor code.

Wouldn't it be easier to just use constructor injection? I use @Inject  
just in Tapestry pages, components and mixins, never in services. In them,  
always constructor injection. It makes it way easier to test them without  
Tapestry-IoC.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org