2016-09-22 1 views
0

J'ai une classe d'entité "classA" et une classe de modèle "ClassA1". ClassA est utilisé pour stocker les valeurs dans la base de données mysql du côté serveur et ClassA1 est utilisé pour convertir une chaîne de réponse API en objet côté client.Comment utiliser une classe java en tant qu'entité et également en tant que modèle

Maintenant, j'ai deux classes java avec les mêmes getters et setters mais ClassA contient des annotations d'hibernation et ClassA1 est simplement un POJO. Tenir compte des structures de classes suivantes

ClassA.java

@Entity 
@Table(name="classA") 
public class ClassA { 
    @Id 
    private int id; 
    private String name; 

    public int getId() { 
     return id 
    } 

    public void setId(int id) { 
     this.id = id; 
    } 

    @Column(name="name") 
    public String getName() { 
     return name; 
    } 

    public void setName(String name) { 
     this.name = name; 
    } 
} 

ClassA1.java

public class ClassA1 { 
    private int id; 
    private String name; 

    public int getId() { 
     return id 
    } 

    public void setId(int id) { 
     this.id = id; 
    } 

    public String getName() { 
     return name; 
    } 

    public void setName(String name) { 
     this.name = name; 
    } 
} 

Ma demande est plus containg nombre de classes comme celle-ci. Je veux éviter cela, car si j'ajoute une colonne à ma base de données, actuellement j'ajoute des getters et setters à la fois dans ClassA et dans ClassA1.

Est-il possible d'utiliser une seule classe pour les modules côté serveur et côté client?

+1

Quel est le problème que vous rencontrez en ayant les deux pareils? –

+0

Si j'utilise une même classe, le modèle côté client charge également un code lié à jpa, ce que je ne veux vraiment pas. – Achaius

+0

@Achaius quel code JPA est chargé? –

Répondre

1

Vous pouvez simplement essayer d'utiliser la même classe dans les deux cas. Ça devrait marcher. C'est comme ça que j'ai essayé au début d'un de mes premiers projets. Tant que vous pouvez traiter avec soin la fusion JPA du ClassA vous avez reçu du côté client en traitant cela comme une entité détachée. Cependant, lorsque la conception de votre entité devient plus compliquée, vous devrez faire face à beaucoup de problèmes (et c'est pourquoi je me suis détourné de cette approche dans mon projet: P). Un des plus gros problèmes est que, étant donné que vous avez modélisé les relations d'entité, une fois que vous essayez de le "sérialiser" pour un usage client, beaucoup de solutions (JAXB etc, à l'époque où je faisais les projets) vont suivre récursivement toute la relation et essaye de la convertir. Un tel comportement déclenchera une extraction paresseuse massive des entités, et rendra la forme sérialisée du résultat contenant une énorme quantité de données (inutilisées). Bien que vous puissiez contrôler le comportement (en ajoutant une sorte d'annotation ignorer, etc.), l'entité résultat deviendra difficile à maintenir.

Par conséquent ce que vous faites, à mon humble avis, n'est pas déraisonnable. Ce qu'il faut faire attention, c'est de traiter l'objet de valeur (ce que vous appelez "Modèle") comme quelque chose de "présentation". Vous n'avez pas besoin de le rendre strictement identique à vos entités. Utiliser/développer une bibliothèque util pour gérer la construction de l'objet valeur à partir d'entités, et remplir les données de l'objet valeur vers les entités.

Bien sûr, la suggestion peut ne pas s'appliquer à vous, étant donné que vous n'avez pas beaucoup partagé votre architecture.

1

Vous pouvez spécifier vos mappages Hibernate séparément dans un fichier XML au lieu d'utiliser des annotations. C'est la vieille façon de le faire, de nos jours la plupart des gens utilisent les annotations parce que c'est plus pratique et suit la norme JPA (surtout).

Une autre solution consiste à utiliser un cadre de mappage de beans tel que Dozer pour faciliter le mappage.

Il est assez fréquent de séparer vos entités persistantes (JPA) et de valoriser les objets utilisés par les vues de votre architecture. Vous pouvez personnaliser les objets de valeur pour la vue dans laquelle ils sont utilisés. Peut-être que la vue n'a pas besoin de l'entité utilisateur complète, mais seulement de l'identifiant, du nom et de l'adresse?Si tel est le cas, cela rend la communication entre view et backend plus légère et résout partiellement la duplication entre vos ValueObjects et les entités persistantes.