On 20.06.2011, at 19:40, Pinaki Poddar wrote:
> Hi,
> > In rich domain entities it is often required to get a reference to an EntityManager to be able to create and
> > persist new entities or to perform queries.
>
> JPA has deliberately took the route where a persistent domain model is orthogonal to persistence context. A persistent object is *managed by* a persistence context, but a persistent object *should not* operate on a persistence context. This suggestion would violate that key decision.
+1 for *should not*. But it has to be possible without hacks.
>
> The idea was not to save the developer by denying them a facility (that does seem lucrative, but unhealthy in the long run, like fast food), but to maintain a consistent semantics of the API itself (essentially we are saving ourselves, not the developers :)
"The idea was not to save the developer by denying them a facility"
It was the main criticism on J2EE - the attempt to save the developer... :-)
>
> > I have the issue in every non-trivial project with a rich domain object model.
>
> The richness of a persistent domain object model stems from its ability to warranty referential integrity (e.g. maintaining consistency of bi-directional relational, or enforcing finite cardinality of a -to-many relation etc) that relates to its persistent properties.
>
> The example of Bike/Training cited shows a different aspect : computing averages (essentially a set based computation that JPA does support via query). The only issue is that computational logic should reside *outside* the domain object scope in a place that has natural access to persistence context and the persistent objects.
" The only issue is that computational logic should reside *outside* the domain object scope"
Computational logic is the whole point of objects. If it resides outside, you will end up with code duplication like:
http://www.antiifcampaign.com/
>
>
> Regards --
>
> Pinaki Poddar
> Apache OpenJPA Chair http://openjpa.apache.org/
> JPA Expert Group Member
> Application & Integration Middleware
>
>
>
>
>
>
>
>
> From: Adam Bien <abien_at_adam-bien.com>
> To: jsr338-experts_at_jpa-spec.java.net
> Date: 06/18/11 03:53 AM
> Subject: [jsr338-experts] EntityManager access in the entities
>
>
>
> Hi All,
>
> I would like to introduce a LifecycleListener and Lifecycle Call Back methods like:
>
>
> @PostAttach
> public void postAttach(EntityManager manager){
>
> }
>
> @PreDetach
> public void preDetach(){}
>
> Reason:
>
> In rich domain entities it is often required to get a reference to an EntityManager to be able to create and persist new entities or to perform queries.
>
> Currently it is only possible with workarounds like using ThreadLocal or ThreadSynchronizationRegistry. With an extension of the lifecycle listener you would get
> a reference to an EntityManager and will get notified in case it is no more valid.
>
> Injection of the EntityManager would be the best/easiest solution, however JPA-entities are managed by the EntityManager and not by the container...
>
> I have the issue in every non-trivial project with a rich domain object model. There are, however, no issues with an anemic (http://www.martinfowler.com/bliki/AnemicDomainModel.html) model, because usually the EJBs / CDI managed beans do implement the business logic.
>
> see also: http://www.adam-bien.com/roller/abien/entry/why_sometimes_the_entitymanager_in
>
> best regards,
>
> adam
>
>