This is a very good summary. I would add one very important consideration that is not often obvious until far too late.
If you think you want to eventually use database transactions (and you're really missing out on a great thing not to use them), the service method interfaces that your view layer uses should *also* be transaction boundaries. Why? Mostly because frameworks like Spring will allow you to simply throw an exception from service layer code to have the transaction automatically rolled back. It's transparent and super effective! But there's a problem if your view code calls more than one write method in the service layer for a single view layer unit of work (such as a form submission). If the first call succeeds and commits it's transaction and the second one fails, the second service method can't unroll the commit of the first. For this reason, I tend to model my service interfaces very closely to what happens in a single unit of work in the user interface. Thinking about transaction demarcations like this will take you a long way toward developing great service interfaces. Cheers, Brian On Aug 30, 2010, at 12:58 PM, Alexander Morozov wrote: > > Hi Sebastian, > > I think that service layer have to be responsible only for CRUD operations, > but L(list) operations should be built upon JPA-specific _READ-ONLY_ queries > or some kind of DSL (for example, querydsl > http://source.mysema.com/display/querydsl/Querydsl). The last one point > allows to build quite complex queries w/o affecting service layer. > > So we have: > 1. fine-graned business logic separated by service interface > 2. service interface implementation incapsulates CRUD-operation > 3. data provider uses specific service interface (in case of simple objects > list) or "query dsl" > > Hopes it helps a little :) > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/OT-Best-practices-regarding-service-layers-DAOs-tp2400408p2400436.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > 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
