Alexander, If I understand you correctly, you are saying: view-only operations (e.g. listings, search forms) can access the DAOs directly, and all operations that modify data should be routed through the service layer? How do you deal with enforcing security constraints (e.g. user X with role Y can only see records created by himself)? I'd like to keep such things out of the view (wicket), so that when I also want to expose say a webservice or REST interface I do not need to duplicate the constraints checks and enforcement.
Brian, I'm using warp-persist (which will be superseded by guice-persist shortly), which provides transactional semantics comparable to Spring. This is also one of the reasons I started building services: to have a clear boundary for transactions. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/OT-Best-practices-regarding-service-layers-DAOs-tp2400408p2400503.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
