Re: JPA+hibernate merge vs find fetching lazy collection

From:

Tom Anderson <twic@urchin.earth.li>

Newsgroups:

comp.lang.java.programmer

Date:

Wed, 6 Jan 2010 10:45:12 +0000

Message-ID:

<alpine.DEB.1.10.1001061044380.16320@urchin.earth.li>

On Mon, 4 Jan 2010, Lew wrote:

Lew wrote:

Entity objects are not really meant for a lot of manipulation outside
the JPA context or by application logic.

Tom Anderson wrote:

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

...

Tom Anderson wrote:

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.
...
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 :).

IOW, "Entity objects are not really meant for a lot of manipulation outside
the JPA context."

Uh, that's not a paraphrase of what i wrote.

tom

--
Mpreg is short for Male Impregnation and I cannot get enough. -- D