Oscar, Matt: thanks for your clarifications. Transactions was also
something that came to my mind when I was thinking about what could go
in a service layer. I'll have a look for more info in the list archives.
Ger-Jan
Matt Raible wrote:
Oscar is correct. There's nothing prevent you from using DAOs directly
in your Actions, but I generally use them to aggregate calls to DAOs.
Also, transactions are set to happen at the Manager level rather than
DAOs. There's lots of similar questions on the mailing list - you
might want to do some searching. Also, notice that for code
generation, we warn users:
http://appfuse.org/display/APF/AppFuse+Maven+Plugin
<quote>
Stop and think before generating code!
At first, I didn't want to add a code-generation feature like this
because you end up with a 1-to-1 relationship between tables/pojos,
DAOs and Managers. On most of my projects, I have far fewer DAOs and
Managers than POJOs.
</quote>
Matt
On Tue, Mar 3, 2009 at 7:38 AM, oscar perez
<oscarfernando.pe...@gmail.com> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net
For additional commands, e-mail: users-h...@appfuse.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net
For additional commands, e-mail: users-h...@appfuse.dev.java.net
