[hibernate-dev] Possibly interesting use of Jandex

[Steve Ebersole]

There are actually lots of great use cases for pure persistence models.
 Prototyping, modeling, designing is one as Sanne mentioned.  "Dynamic"
models is another.  You see this is envers, grails, and other places.

Also, whether *you* think persistence models should or should not be anemic
is fine.  That's your choice.  Not everyone in the world needs to agree
with you ;)


On Tue, Mar 11, 2014 at 12:17 PM, Sanne Grinovero <sanne at hibernate.org>wrote:

> On 11 March 2014 17:08, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> >
> >
> > 2014-03-11 17:45 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >
> >> On 11 March 2014 10:59, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> > 2014-03-09 18:31 GMT+01:00 Steve Ebersole <steve at 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.
>
> Sanne
>