Re: [Springframework-developer] TransactionProxyFactoryBean definitions in Petclinic

[Colin S. <col...@ex...>]

I'm not so sure I agree. Over and over we see people using the samples 
almost as is in terms of being a base template for their apps, so if we 
don't show the best practices there, where do we? And I would be 
surprised if anybody with more than 2 or 3 proxies would not want to use 
the parent child idiom, to reduce verbosity. I guess this is reallly a 
question of who the Petclinic audience is... In any case, showing both 
forms (in terms of a presentation) is actually a good way of showing the 
difference that using parent and child definitions can make, and how 
they work.

I'll add a comment in there anyways pointing people to the other form in 
the manual and JPetStore, as a preferred form for most uses when there 
are more than a couple of proxies.


jürgen höller [werk3AT] wrote:

>FYI, I've modified the TransactionProxyFactoryBean definitions in Petclinic back to the simple direct version. The version with a "baseTransactionProxy" in case of a single transaction proxy arguably obscured the intent, at least in this simple sample application.Petclinic is meant to be as bare bones and trivial as possible, being useful as an example in introductory workshops that illustrate very basic principles of a Spring middle tier.
> 
>On numerous occasions, I showed a Petclinic applicationContext.xml file without having explained parent/child bean definitions before. I always had to argue that this was using a parent bean definition here, but that this parent/child stuff wasn't important for our current discussion. My slides showed a direct TransactionProxyFactoryBean definition too.... I'm convinced now that it is better for the intended Petclinic audience to show the simple direct case.
> 
>I've left the "baseTransactionProxy" separation in JPetStore, though, which is generally somewhat more sophisticated in its middle tier, with multiple fine-grained DAOs etc. IMO, it is sufficient to show the separation there; we don't need to build this into more than one sample application. A parent/child TransactionProxyFactoryBean definition is harder to understand than the simple direct case, after all, even it's recommended for advanced usages.
> 
>Juergen
>  
>