Exactly what you mention was the reason I thought to define it on the
interface itself. That way you would enforce that it was used only
once. But I totally understand about the awkwardness of the
"bi-directionality".
Good point about the separating.
On Fri 09 Mar 2012 01:50:31 PM CST, Oliver Gierke wrote:
> Hi all,
>
> great idea. Would it make sense to invert the mapping to point from the implementation class to the interface as a mapping the other way round would effectively create a bidirectional dependency. The interface referring to it's implementation feels a bit weird. What about
>
> public interface Person {
> …
> }
>
> @Entity(typeAliasFor = Person.class)
> public class PersonImpl implements Person {
> …
> }
>
> The persistence provider would then reject mapping constellations where more than one implementation class refers to the interface as type alias. With a mapping this way round one could even have interface and implementation in separate JARs being brought together at runtime.
>
> Cheers,
> Ollie
>
> Am 09.03.2012 um 19:04 schrieb Steve Ebersole:
>
>> I'd like to propose that JPA 2.1 allow @Entity on Java interfaces not
>> just classes. The main reason is typing in spec contracts. For domain
>> models that leverage interfaces, it is usually desirable to deal with
>> the interfaces over the implementation classes. For example, such
>> applications would generally prefer to attempt to load or get a
>> reference to an instance based on the interface name as opposed to the
>> class name. E.g.
>>
>> public interface Person {
>> ...
>> }
>>
>> @Entity
>> public class PersonImpl implements Person {
>> ...
>> }
>>
>> EntityManager em = ...;
>> Person p = em.find( Person.class, theKey );
>>
>> But this does not work today in a portable manner. To work in the most
>> portable manner, I think the @Entity annotated interface also would need
>> to name the "persistent implementation class":
>>
>> @Entity( impl = PersonImpl.class )
>> public interface Person {
>> ...
>> }
>>
>> public class PersonImpl implements Person {
>> ...
>> }
>>
>> It could be up to each provider whether or not to support @Entity on an
>> interface that did not specify a "persistent implementation class".
>>
>> Another way to look at this is as basically "aliasing" the entity type
>> metadata using the interface name instead of the implementation class name.
>>
>> -Steve
>