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
