Re: [Springframework-developer] TransactionProxyFactoryBean definitions in Petclinic

[<jue...@we...>]

You do have a point, Colin, that we should show best practices in the =
samples. However, splitting a TransactionProxyFactoryBean into a parent =
and a child definition in case of a *single* proxy is not really a best =
practice; doing such a split in case of *multiple* proxies is. Combined =
with the fact that explaining the Petclinic application context becomes =
harder for an introductory audience, I vote for using simple direct =
definitions there (already changed but not committed yet).
=20
Of course, JPetStore just defines a single transactional proxy too... =
However, I wouldn't mind showing the parent/child split there, even for =
a single proxy, as the middle tier of that sample application is =
generally more complex. As long as we clearly point out that we =
recommend the parent/child split in case of multiple proxy definitions, =
it should be sufficent to illustrate this just in JPetStore but not in =
Petclinic.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Sa 13.11.2004 00:32
An: spr...@li...
Betreff: Re: [Springframework-developer] TransactionProxyFactoryBean =
definitions in Petclinic



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=FCrgen h=F6ller [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
>=20
>



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer