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.
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
