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