Quelle est la meilleure pratique dans l'utilisation d'entités JPA?
Comme les entités JPA ne sont que des pojos, est-il considéré comme approprié d'utiliser l'objet comme objet de données dans d'autres parties du système ou de les convertir en un autre objet de données?
est-il acceptable d'utiliser l'entité JPA Pojos dans d'autres parties du système sans rapport avec JPA?
3 Réponses :
Les entités sont maintenant elles-mêmes capables de transporter leurs propres données, alors pourquoi la peine de les convertir en autre chose? En d'autres termes, j'ai tendance à être d'accord avec DTO un anticitatoire dans EJB 3.0 :
Le poids lourd de la nature des haricots d'entité dans les spécifications EJB antérieures à l'EJB 3.0, a abouti à l'utilisation de modèles de conception tels que Objets de transfert de données (DTO). Les DTO sont devenus les objets légers (qui auraient dû être les haricots entités eux-mêmes), utilisés pour envoyer les données sur les niveaux. [...]
EJB 3.0 SPEC fait le modèle de haricot d'entité identique à l'ancien objet Java (Pojo). Avec ce nouveau modèle de pojo, vous n'aurez plus besoin de créer un DTO pour chaque entité ou pour un ensemble d'entités. Si vous souhaitez envoyer les entités EJB 3.0 à travers le niveau, faites-les simplement implémenter
java.io.rserialiazable . .
Vous créditer avec réponse parce que vous êtes lié à une documentation intéressante sur AntiPattern.
Cela dépend de ce que vous voulez dire avec des "autres parties". Étant donné que vos entités JPA doivent être en quelque sorte liées à votre système, pourquoi ne pas les utiliser car ils sont déjà là. Le point important est que vous n'utilisez pas la même classe pour deux préoccupations totalement différentes (qui est alors imho une indication de mauvaise conception ou simplement un système vraiment gros). Tout le reste se retrouvera probablement dans une cartographie sans fin entre vos différents pojos Hassle.
Par exemple, un utilisateur de connexion. Il peut s'agir d'une pratique courante Verbose Java de créer un haricot d'utilisateur distinctLoginform pour une connexion Web basée sur le Web, mais considérez ceci:
Vous avez déjà vos entités JPA de l'utilisateur (et donc un utilisateur POJO) dans la base de données (il dispose d'un nom d'utilisateur, d'un hachage de mot de passe, d'une adresse et probablement d'autres choses stockées). Vous pouvez également utiliser exactement le même objet dans votre demande de connexion du formulaire Web (certains cadres tels que Spring le feront immédiatement). Créez un objet utilisateur vide, définissez le nom d'utilisateur et le mot de passe haché et créez une requête JPA par exemple. Si cette requête renvoie exactement un résultat, le login est valide et vous pouvez stocker l'objet utilisateur chargé dans la session.
C'est une bonne question.
En exposant les classes d'entité JPA au reste du système, vous exposez le mécanisme de persistance et l'objet à la cartographie de la DB.Vous perdez le contrôle sur la manière dont ces objets sont contrariés et gérés. En rompant l'encapsulation de la persistance, un changement peut avoir un effet d'ondulation sur le reste du système.
Les modifications futures de la persistance du système peuvent être impossibles, maladroites, limitées et / ou risquées. Exemple: Vous devrez peut-être optimiser les performances et / ou l'évolutivité. Cela peut nécessiter une mise en cache, des modifications de schéma de DB, une utilisation non RDBMS, plusieurs bases de données. L'encapsulation contribue également à atténuer la migration vers les futurs schémas db.
Le commerce est donc:
La première option peut être nécessaire si des changements fréquents de l'ensemble du système ne sont pas acceptables - par exemple. Les 3e parties accèdent à vos données. Ou peut-être que vous avez décidé d'une architecture de 3 couches: GUI, logique commerciale, persistance.
La deuxième option est correcte si vous avez un processus de développement agile et avez le contrôle de l'ensemble du système et acceptez le fait que le changement de système est nécessaire sur la ligne.