2014-03-11 18:17 GMT+01:00 Sanne Grinovero <sa...@hibernate.org>:
> On 11 March 2014 17:08, Gunnar Morling <gun...@hibernate.org> wrote:
> >
> >
> >
> > 2014-03-11 17:45 GMT+01:00 Sanne Grinovero <sa...@hibernate.org>:
> >
> >> On 11 March 2014 10:59, Gunnar Morling <gun...@hibernate.org> wrote:
> >> > 2014-03-09 18:31 GMT+01:00 Steve Ebersole <st...@hibernate.org>:
> >> >
> >> > @Entity
> >> >> interface Employee {
> >> >> ...
> >> >> }
> >> >>
> >> >> 2) We'd dynamically generate a class to back this. This generated
> >> >> class
> >> >> can contain many of the performance tweaks we've been developing via
> >> >> bytecode extensions (inline dirty-checking, "entity entry" info,
> etc).
> >> >>
> >> >
> >> > In which situation would one make use of this? This seems to encourage
> >> > "anemic data models", i.e. entities which are just data holders but
> >> > don't
> >> > contain any business logic. Often it's very useful though to add logic
> >> > dealing with an entity's state to the entity type itself.
> >>
> >> I actually see this going in the opposite direction. Allowing to move
> >> all the mapping stuff to a different interface would encourage me to
> >> think of the implementation as something which can include code, and I
> >> could even have multiple types having different *implementations* if
> >> the non-persistent methods.
> >>
> >> It would also fight usage of inheritance, which is common among JPA
> >> users and something that I'd gladly avoid.
> >>
> >> Would be a very nice to have to avoid anemic data models.
> >
> >
> > I'm not following. The idea in 2) (which I was referring to) was to
> > *generate* the implementation class. How does a custom implementation
> play
> > into this? Are you referring to alternative 1) maybe?
>
> Sorry I forgot to qualify. I thought it would be nice to have both,
> and 2) would the the fallback approach in case no implementation is
> available.
>
> That would allow the "persistence team" (yes in some places they have
> dedicated teams) be able to create the model as an interface, play and
> test with it, and then another team actually provides an useful
> implementation.
>
> In the scope of the persistence testing, you're fine with the anemic model.
>
Yes, 1) seems useful in some cases.
Regarding an impl fully generated (2), my question still is how users would
construct instances. Would there be a factory method? Also how would
equality be defined?
>
> Sanne
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
