Hi, I think the decoupling dao/service layer is because in the data access layer you access your data without worrying about your business logic. I always think of data layer as small bricks and the service layer being composed with these small bricks. Also, in the service layer there are annotations to use web services so these methods are exposed to external web service clients. HTH, Oscar
On Tue, Mar 3, 2009 at 12:35 AM, Ger-Jan te Dorsthorst <ger...@dds.nl>wrote: > Hi, > > Here's a couple of questions for you architecture boffins: > > It is clear that the source tree of Appfuse is neatly organised. I can see > the purpose of having a dao package with interfaces and one or several > dao/impl packages with specific implementations for those dao classes: it > makes it easy to switch between a Hibernate and a plain JDBC implementation, > for example. > > I guess there must be a similar rationale for the organisation of the > service layer, which is similarly divided in a service package and a > service/impl package. Is that correct? What would be a scenario with > multiple implementations for a service? > > Also, why does the service layer sit between the controllers (web layer) > and the data layer at all? Wouldn't the dao and the web layer be > satisfactorily decoupled by employing dao interfaces? > > I'm sure there's a good reason for the additional structure, but in the > simple web apps I've built so far the service methods seem to be basically > pass throughs to the daos. > > Any enlightenment would be highly appreciated, > > tia, > > Ger-Jan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net > For additional commands, e-mail: users-h...@appfuse.dev.java.net > >
