On Thu, 07 Jun 2012 16:06:31 -0300, skow <r...@skow.org> wrote:
I got the notion that there was a 'Session' service from the code below.
Ah, I've just figured out you were talking about Hibernate's session, not
the Tapestry Session. :P
I think that obtaining the DAO from Tapestry-IoC is where I'm getting
confused. If the User 'business object' was created with a regular
'new', is it possible for it to obtain a UserDAO from Tapestry-IoC?
I'd create a service for being a factory of User objects (maybe other
classes too). In this service, you can inject ObjectLocator, which is the
interface that allows you to get service instances programmatically
(getService() methods).
Related to the initial architecture - I certainly respect your point of
view on the Entities using DAOs directly. Although I don't want to go
too off
topic, but I am interested in your preferred architecture. Do you use a
separate 'business object' and treat the Entity as only a ValueObject
with getters/setters?
I use a separate object, which some people call controller class (not the
controller from MVC). I think that imposing entity classes as purely value
objects suck, being something very not OOP.
My rationale is this: I put inside the entity all the logic that can be
implemented without using DAOs and services. In other words, all logic
that can implemented by using the object state (fields) Example: an Order
class would have a field containing a list of OrderItem's, each one with
its value. The getTotalValue() method would be place in Order, as this
class has all the info it needs to do that. Logic which doesn't fit in
this model go to controller classes. I typically have one for each entity
class.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org