Est-il possible de construire une entité JPA par l'extension d'un POJO?

Permet de dire que j'ai le texte suivant POJO:

public class MyThing {
 private int myNumber;
 private String myData;
//assume getter/setter methods
}

Est-il maintenant possible d'étendre cette POJO comme une entité JPA?

@Entity
@Table(name = "my_thing")
public class MyThingEntity extends MyThing implements Serializable {
 @Column(name = "my_number")
 //?????????
 @Column(name = "my_data")
 //????????
}

Je veux garder le POJO distincte de l'entité JPA. Le POJO vit dans un projet différent et est souvent utilisé sans une couche de persistance, mon projet veut persister dans une base de données et de le faire sans l'aide de la cartographie à partir d'un POJO à une entité et à l'arrière.

Je comprends que des entités JPA sont des Pojo, mais pour les utiliser il me faudrait inclure une bibliothèque qui implémente javax.la persistance et les autres projets à l'aide de la même objet de base n'ont aucune utilité pour une couche de persistance.

Est-ce possible? Est-ce une bonne idée?

InformationsquelleAutor Freiheit | 2010-03-25
  1. 70

    Spécification JPA états

    Entités peut s'étendre non-classes d'entité ainsi que les classes d'entité, et non les classes d'entité peut étendre les classes d'entité.

    @javax.la persistance.MappedSuperclass annotation vous permet de définir ce type de cartographie

    @MappedSuperclass
public class MyThing implements Serializable {
    private int myNumber;
    private String myData;

    //getter's and setter's
}

    Et

    @Entity
@Table(name="MY_THING")
public class MyThingEntity extends MyThing {


}

    Comme l'a dit par la spécification JPA

    La MappedSuperclass annotation désigne une classe dont la cartographie de l'information est appliquée aux entités qui héritent de ce.

    Et

    Une classe désignée par la MappedSuperclass annotation peut être défini de la même manière comme une entité, sauf que les mappages ne s'appliquent qu'à ses sous-classes depuis aucune table n'existe pour le mappé super-classe elle-même.

    Si vous avez besoin de remplacer certains biens définis par MyThing, utilisez @AttributeOverride (lorsque vous voulez remplacer une seule propriété) ou @AttributeOverrides (lorsque vous voulez remplacer plus d'une propriété)

    @Entity
@Table(name="MY_THING")
@AttributeOverride(name="myData", column=@Column(name="MY_DATA"))
public class MyThingEntity extends MyThing {


}

    Et

    @Entity
@Table(name="MY_OTHER_THING")
@AttributeOverrides({
    @AttributeOverride(name="myData1", column=@Column(name="MY_DATA_1")),
    @AttributeOverride(name="myData2", column=@Column(name="MY_DATA_2"))
})
public class MyOtherThingEntity extends MyThing {

}

    Si vous ne voulez pas changer votre classe de base, vous pouvez utiliser le format xml pour le définir comme @MappedSuperClass

    Attention: par défaut, le fournisseur de persistance dans le répertoire META-INF pour un fichier nommé orm.xml

    <?xml version="1.0" encoding="UTF-8"?>

<entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd" version="1.0">
    <mapped-superclass class="MyThing">

    </mapped-superclass>
</entity-mappings>

    Rien d'autre. Si vous souhaitez remplacer une propriété, utilisez @AttributeOverride comme indiqué ci-dessus

    • je crois que l'idée n'est pas de changer le MyThing classe
    • Maxime est correct, je ne veux pas toucher à la base de POJO à tous. Il peut toujours fonctionner, @MappedSuperclass MyThingMapper extends MyThing .... MyThingEntity extends MyThingWrapper
    • Ajouté à l'original de la réplique
    • Accepté. Maintenant je suis sur de mettre en œuvre une preuve de concept et de faire le pitch de mon équipe! Merci Arthur!
    • Juste un conseil. Jetez un oeil à Appress Pro EJB 3 - le PACKAGING ET le DÉPLOIEMENT
    • Que faire si vous voulez faire myNumber la clé primaire de MyThingEntity?
    • Santos il suffit de placer l'Id d'annotation au-dessus d'elle. Cependant, n'oubliez pas: vous devez définir un, et un seul, la clé primaire par hiérarchie de classe.
    • Est-il possible d'ajouter la clé primaire sans modification de l'entité de base, de la même façon @AttributeOverride est utilisé pour les colonnes?
    • La seule chose que j'ai oubliée de cette réponse, c'est un lien vers la documentation officielle
    • Quelques notes après avoir essayé ce que: 1) META-INF est situé dans src/main/resources/META-INF. 2) @AttributeOverride n'est pas nécessaire si vous êtes bien avec les noms d'attribut, le nom des colonnes.
    • avez-vous trouvé une solution pour ajouter une clé primaire?
    • Hallak Vous ne pouvez pas. C'est une question de cohérence
    • Peut-on hériter d'une non-entité de la classe sans annoter MappedSuperclass?
    • Dans cet exemple, une attributeOverride est utilisé pour myData1 et myData2. Cependant, ces champs n'existent pas dans la classe parent MyThing. De ce que je peux voir dans la javadoc qui ne serait pas valide

    InformationsquelleAutor Arthur Ronald
  2. 6

    Il est possible:

    • vous pouvez mapper avec XML - faire un orm.xml (conforme à la orm schéma), et de mapper les colonnes de votre POJO, sans même l'étendre. Il sera JPA-activé dans un environnement et d'un POJO dans l'autre
    • remplacement simplement les méthodes de lecture et de les annoter - (je ne sais pas si cela va fonctionner)

    Cela dit, je ne pense pas qu'il est nécessaire pour ce faire. Seulement d'annoter vos POJO, et ajouter à la compilation de la dépendance du temps pour vos projets. Ensuite, chaque projet doit décider si elle va les utiliser comme des entités JPA ou pas.

    • Notez que vous devez trouver un moyen d'avis lorsque le POJO est modifié de sorte que vous pouvez modifier votre fichier de mappage.
    • Supposons maintenant que l'équipe d'exécution du projet qui a le POJO ne seront en aucun cas me permettre de soumettre un patch avec les annotations JPA et un javax.la persistance de l'importation. Est-il une telle chose comme un "dummy" javax.la persistance de la bibliothèque ainsi l'importation des œuvres, mais theres aucun besoin de faire glisser EclipseLink Pots si la persistance n'est pas voulu?
    • Les annotations ne suffira pas à provoquer une exécution de problème, même si le pot contenant n'est pas présent. Il serait encore nécessaire au moment de la compilation. Je ne suis pas sûr de l'endroit où tout est disponible, mais Maven a un javax.persistence-persistence-api-1.0.jar dans le référentiel (mvnrepository.com/artifact/javax.persistence/persistence-api/...).
    • C'est effectivement très intéressant. La raison pour laquelle nous ne pouvons pas "polluer" le POJO avec les annotations, c'est que son utilisé par plusieurs autres projets et d'avoir à glisser autour d'un Maven ou Eclipselink POT de fournir javax.les classes de persistance n'est pas acceptable. Donc, à partir de ce que vous dites, nous pouvons construire avec ces Pots de présenter ensuite les distribuer sans eux dans des projets qui n'ont pas besoin de JPA.
    • Oui, tant que juste les annotations sont utilisées (les énumérations sont ok aussi, tant qu'ils sont seulement utilisés dans les annotations), JPA n'a pas besoin d'être présent au moment de l'exécution.
    InformationsquelleAutor Bozho