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.

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.

On Jun 19, 2010, at 8:07 AM, James Carman wrote:

> Why do you have page -> service -> dao?  Why not just talk directly to
> the DAO for the getAll() method.  This level of indirection just
> causes more code (and confusion) in your simple example.  Is this just
> a "best practice" that you've devised?  I've never really understood
> folks' aversion to talking to the DAOs from the view layer, especially
> when it means you have to have duplicate methods in your service layer
> to do so.  It just doesn't make sense to me.
> 
> 
> On Sat, Jun 19, 2010 at 8:01 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> Why is spring-orm version 3.0.1.RELEASE and not 3.0.3.RELEASE?  Why
>> not just uset a {spring.version} property in your POM so that it all
>> stays in synch?
>> 
>> On Sat, Jun 19, 2010 at 7:23 AM, Kent Tong <k...@cpttm.org.mo> wrote:
>>> Hi,
>>> 
>>> I've written a tutorial on this topic. You may check it out at
>>> http://www.dzone.com/links/getting_started_with_scala_spring_hibernate_wicket.html
>>> 
>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>> 
>>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 


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

Reply via email to