Pourquoi Hibernate ne requiert-il pas de constructeur d'argument ?

Question

Le constructeur sans argument est une exigence (des outils comme Hibernate utilisent réflexion sur ce constructeur pour instancier les objets).

J'ai obtenu cette réponse à la main mais quelqu'un pourrait-il m'expliquer davantage ? Merci

Answer 1

Hibernate, et le code en général qui crée des objets via la réflexion utilisent [Class<T>.newInstance()](http://java.sun.com/javase/6/docs/api/java/lang/Class.html#newInstance()) pour créer une nouvelle instance de vos classes. Cette méthode nécessite un constructeur public no-arg pour pouvoir instancier l'objet. Pour la plupart des cas d'utilisation, fournir un constructeur no-arg n'est pas un problème.

Il existe des astuces basées sur la sérialisation qui peuvent contourner l'absence d'un constructeur sans argument, puisque la sérialisation utilise la magie de JVM pour créer des objets sans invoquer le constructeur. Mais ceci n'est pas disponible sur toutes les VMs. Par exemple, XStream peut créer des instances d'objets qui n'ont pas de constructeur public sans argument, mais seulement en s'exécutant dans un mode dit "amélioré" qui n'est disponible que sur certaines VM (voir le lien pour plus de détails). (Voir le lien pour plus de détails.) Les concepteurs d'Hibernate ont sûrement choisi de maintenir la compatibilité avec toutes les VM et évitent donc de telles astuces, et utilisent la méthode de réflexion officiellement prise en charge Class<T>.newInstance() nécessitant un constructeur sans argument.

Answer 2

Hibernate instancie vos objets. Il doit donc être capable de les instancier. S'il n'y a pas de constructeur no-arg, Hibernate ne saura pas que l'objet a été instancié. comment pour l'instancier, c'est à dire quel argument passer.

Le site documentation hibernate dit :

4.1.1. Implémenter un constructeur sans argument

Toutes les classes persistantes doivent avoir un constructeur par défaut (qui peut être non public) afin qu'Hibernate puisse les instancier à l'aide de la fonction Constructor.newInstance() . Il est recommandé de disposer d'un constructeur par défaut avec au moins la visibilité du package pour la génération de proxy à l'exécution dans Hibernate.

Answer 3

L'hibernate est un cadre ORM qui prend en charge la stratégie d'accès aux champs ou aux propriétés. Cependant, il ne prend pas en charge le mappage basé sur les constructeurs - ce que vous aimeriez peut-être ? - à cause de certains problèmes comme

1º Que se passe-t-il si votre classe contient beaucoup de constructeurs ?

public class Person {

    private String name;
    private Integer age;

    public Person(String name, Integer age) { ... }
    public Person(String name) { ... }
    public Person(Integer age) { ... }

}

Comme vous pouvez le constater, vous êtes confronté à un problème d'incohérence car Hibernate ne peut pas savoir quel constructeur doit être appelé. Par exemple, supposons que vous ayez besoin de récupérer un objet Personne stocké

Person person = (Person) session.get(Person.class, <IDENTIFIER>);

Quel constructeur Hibernate doit-il appeler pour récupérer un objet Personne ? Pouvez-vous voir ?

2º Enfin, en utilisant la réflexion, Hibernate peut instancier une classe par le biais de son constructeur sans argument. Ainsi, lorsque vous appelez

Person person = (Person) session.get(Person.class, <IDENTIFIER>);

Hibernate instancie votre objet Personne de la manière suivante

Person.class.newInstance();

Ce qui, selon la documentation de l'API

La classe est instanciée comme par une nouveau avec une expression vide liste d'arguments

Morale de l'histoire

Person.class.newInstance();

est similaire à

new Person();

Rien d'autre

Answer 4

Hibernate a besoin de créer des instances comme résultat de vos requêtes (via la réflexion), Hibernate s'appuie sur le constructeur no-arg des entités pour cela, vous devez donc fournir un constructeur no-arg. Qu'est-ce qui n'est pas clair ?

Answer 5

En fait, vous pouvez instancier des classes qui n'ont pas de constructeur 0-args ; vous pouvez obtenir une liste des constructeurs d'une classe, en choisir un et l'invoquer avec de faux paramètres.

Bien que cela soit possible, et je suppose que cela fonctionnerait et ne poserait pas de problème, vous conviendrez que c'est plutôt bizarre.

La construction d'objets comme le fait Hibernate (je crois qu'il invoque le constructeur à 0 argument, puis modifie probablement les champs de l'instance directement via Reflection. Peut-être sait-il comment appeler les setters) va un peu à l'encontre de la façon dont un objet est censé être construit en Java - invoquer le constructeur avec les paramètres appropriés pour que le nouvel objet soit celui que vous voulez. Je pense que l'instanciation d'un objet et sa mutation sont en quelque sorte " anti-Java " (ou je dirais, anti-Java théorique pur) - et il est certain que si vous le faites via la manipulation directe des champs, cela va à l'encontre de l'encapsulation et de tous ces trucs d'encapsulation fantaisistes.

Je pense que la bonne façon de faire serait de définir dans le mapping Hibernate comment un objet devrait être instancié à partir des informations de la ligne de base de données en utilisant le constructeur approprié... mais cela serait plus complexe - ce qui signifie qu'Hibernate serait encore plus complexe, le mapping serait plus complexe... et tout cela pour être plus "pur" ; et je ne pense pas que cela aurait un avantage sur l'approche actuelle (autre que de se sentir bien de faire les choses "de la bonne façon").

Cela dit, et vu que l'approche d'Hibernate n'est pas très "propre", l'obligation d'avoir un constructeur à 0 argument n'est pas strictement nécessaire, mais je peux comprendre quelque peu cette exigence, même si je crois qu'ils l'ont fait pour des raisons purement "appropriées", alors qu'ils se sont éloignés de la "bonne méthode" (bien que pour des raisons raisonnables) bien avant cela.