On Sat, Jun 19, 2010 at 11:54 AM, Brian Topping <brian.topp...@gmail.com> wrote:
> The best reason for me to keep a service/business layer talking to the DAO is 
> to provide a clean transactional boundary.  Then, all I have to do is add a 
> Spring @Transactional annotation to the method and I'm fully atomic.
> If my view logic is calling a half dozen DAO methods to effect an update, 
> there's no way to have a single method demarcate the transaction.  Without a 
> single method, no use of @Transactional, and I have to maintain complex 
> transactional code by hand.  This is way more error prone and complex than 
> taking (what are admittedly attractive) shortcuts to remove the service layer.

You can also annotate your Wicket pages/components methods with the
@Transactional annotation if you use the AspectJ compiler.  They have
to be public or protected in order for the compiler to pick them up
and weave them I believe.  No big deal, in practice, really.

> As a bonus, with well-defined service layer interfaces, I can easily generate 
> SOAP or REST interfaces and expose them to other fat clients like mobile 
> devices in the future.

Agreed, but having one method that merely delegates to another is just
plain silly, IMHO.  You'd probably generate custom services that are
tailored to the different view implementations so that you can
aggregate things correctly for optimization purposes.

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to