[Orchestra] Binding an arbitrary instance to a conversation

[Simon Kitching <sk...@apache.org>]

Hi,

As all of you who carefully read commit-messages may have seen (:-), 
yesterday I committed the ability to call
  Conversation.bind(instance)
so that later calls to any method on that instance will run within the 
context of the specified conversation (including its associated 
persistence context if any) [1].

This is useful functionality and I don't think anyone will object. There 
is one question about the actual implementation, though, that I thought 
people might have an opinion on.

The current approach adds interface ConversationBinder, and a setter 
method has been added to the Conversation class. Each 
dependency-injection-specific layer then provides a different 
implementation of this (eg SpringConversationBinder) when creating 
Conversation instances.

An alternative would be for each dependency-framework to instead return 
a subclass of Conversation, then the binder interface would not be 
needed. This approach would potentially be more extensible in future 
(any future new features requiring tight couplings between conversation 
and dependency-injection-framework can just be added transparently 
without new interfaces) but would make the Conversation class a little 
harder to understand IMO.

Both seem reasonable to me; anyone got arguments about preferring one 
over the other? Or any other issues about those patches in general?

[1] Mario came up with this idea, and did an initial prototype.

Regards,
Smion

Re: [Orchestra] Binding an arbitrary instance to a conversation

[Matthias Wessendorf <ma...@apache.org>]

On Thu, Oct 9, 2008 at 10:20 AM, Simon Kitching <sk...@apache.org> wrote:
> Hi,
>
> As all of you who carefully read commit-messages may have seen (:-),
> yesterday I committed the ability to call
>  Conversation.bind(instance)
> so that later calls to any method on that instance will run within the
> context of the specified conversation (including its associated persistence
> context if any) [1].
>
> This is useful functionality and I don't think anyone will object. There is
> one question about the actual implementation, though, that I thought people
> might have an opinion on.
>
> The current approach adds interface ConversationBinder, and a setter method
> has been added to the Conversation class. Each dependency-injection-specific
> layer then provides a different implementation of this (eg
> SpringConversationBinder) when creating Conversation instances.
>
> An alternative would be for each dependency-framework to instead return a
> subclass of Conversation, then the binder interface would not be needed.
> This approach would potentially be more extensible in future (any future new
> features requiring tight couplings between conversation and
> dependency-injection-framework can just be added transparently without new
> interfaces) but would make the Conversation class a little harder to
> understand IMO.

from what I read, I think I like this second option more, since it promises
a better, more extensible, approach.

>
> Both seem reasonable to me; anyone got arguments about preferring one over
> the other? Or any other issues about those patches in general?
>
> [1] Mario came up with this idea, and did an initial prototype.

Mario, we miss you!

-Matthias

>
> Regards,
> Smion
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [Orchestra] Binding an arbitrary instance to a conversation

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> The current approach adds interface ConversationBinder, and a setter 
> method has been added to the Conversation class. Each 
> dependency-injection-specific layer then provides a different 
> implementation of this (eg SpringConversationBinder) when creating 
> Conversation instances.
>
> An alternative would be for each dependency-framework to instead 
> return a subclass of Conversation, then the binder interface would not 
> be needed.
A simialar pattern I tried to achive with the framework adapter, you 
have a basis class everyone can inherit from and implement the required 
functionality.
IMHO the framework adapter shows the bad side of that pattern. The 
framework adapter just collects various aspects of the used framework 
and tries to provide a common api for Orchestra.
When we think of "aspects" here, it would have been better to build 
small pieces for each aspect of the framework (spring, jsf, jsp, junit) 
and let the framework adapter just delegate to them.

Said that, I think your ConversationBinder is in the same category of 
patterns.

The Conversation object itself is not bound to, nor does it depend on, 
any environment. Going the subclass way will change that. Now the 
Conversation instance itself depends on Spring then.
What, if in the future we are going to add other aspects to the 
Conversation which then depends on JSF?
Without multiple inheritance we might end up with many different 
conversation implementations.

I'd keep your solution (ConversationBinder interface) which will become 
much more powerfull the more aspects we add to the Conversation.

Ciao,
Mario