Re: JPA+hibernate merge vs find fetching lazy collection
On Sun, 3 Jan 2010, Arved Sandstrom wrote:
Tom Anderson wrote:
On Sat, 2 Jan 2010, Arved Sandstrom wrote:
Tom Anderson wrote:
On Wed, 30 Dec 2009, Lew wrote:
Entity objects are not really meant for a lot of manipulation outside
the JPA context or by application logic.
No, no, no. JPA is a mechanism, not a policy - JPA entities are not
'meant' for anything. You might think it's a good idea to use JPA
entities that way, but it's something i'd disagree very strongly with you
over - what you're advocating is an Anemic Domain Model, and it's a bad
thing (Martin Fowler says so, so it must be true! :) ):
http://martinfowler.com/bliki/AnemicDomainModel.html
I'm in general agreement with what's said in that link. However, in the
context of JPA, I myself don't think of the entity classes by themselves
as defining the domain layer in its entirety. I don't think of JPA entity
classes as being domain classes at all, not by definition. Some happen to
correspond to domain classes, some don't. To me JPA entity classes are
fine-grained Java mappings to RDBMS tables, and that's about it. They are
at the same level as iBatis mapping files.
I tend to think of DAOs, which map to the real domain classes, as being
the domain layer. Some JPA entities happen to have a 1:1 mapping to a
domain class - many do not, and really aren't more than value objects or
DTOs.
Interesting. Are you essentially using JPA entities as behind-the scenes
data holders, wrapped by real domain objects? Or are you saying your domain
objects are more like a service layer? Could i trouble you for a very small
example of this, just in outline?
Assuming your email is good, I can sanitize some work stuff and send some
examples that way.
It is good, and that would be most kind - but only if it's not too much
trouble. I can then try to synthesise a noddy example to demonstrate your
approach, which i'll post to the group (and you can tell me if i've got it
right!).
We just recently went through this exercise on a client site, where
several apps had JPA but no data access layer (i.e. persistence code was
scattered everywhere, including in the web tier), and in the course of
building a DAL we realized that the DAOs most useful to the service
layer (or to other DAOs in the domain layer) really did not, in most
cases, map 1:1 to JPA entities.
But the key thing here is that you have a strong service layer - the DAOs
are almost a detail, i suspect. The service layer is where the business
logic lives, and JPA just supplies structs full of data to it.
Yes, in a nutshell, in this picture JPA entities are both behind-the-scenes
and low-level. Basically data holders as you say.
As one very simple example, if you have two JPA entities related by a
OneToMany/ManyToOne, and that's logically a strong composition
relationship, it's probably more useful to have a single DAO that
handles both entities. Logically the real domain object is the parent +
those entities that can only co-exist with the parent. JPA does provide
some facilities like @Embedded and @Embeddable to handle some of this
for 1:1 situations), but I personally prefer to dispense with
annotations like these, and to have explicit domain logic manage
composition or aggregation relationships.
Fair enough. I was thinking that in JPA2 you can do aggregation with a
CollectionOfElements that holds Embeddables, so the contained objects
don't need to be entities. But this is, to some extent, jumping through
hoops in order to maintain a somewhat arbitrary kind of purity.
As an aside, I'm not entirely happy with that Fowler link (nor with Eric
Evans :-)). If I read it correctly they are suggesting that business
rules live only in the domain layer (this is using their definitions of
domain and service layers). I don't buy that - I think there are 2 types
of business rules, and one set lives in the service layer.
Qualitatively different types? This is an intuitively attractive idea -
domain objects model the entities in the domain, with their natural,
intrinsic behaviour (eg valuing and repaying a mortgage), and the service
layer captures more transaction-script type behaviour (selling someone a
mortgage), if that's what you mean. This is an idea that goes all the way
back to the dawn of EJB, if not before. Is it right? Dunno. I'd be
interested to see how some big server-side Smalltalk systems did it :).
tom
--
Exceptions say, there was a problem. Someone must deal with it. If you
won't deal with it, I'll find someone who will.