dans mes classes hibernate si les collections d'instance doivent être initialisées ou gauche inintitualisée fait une sorte de différence pour hibernate ? Je suis tombé sur ce hibernate Documentation où il initialise leur hashset, mais je les ai souvent vus laissés ininitialisés.
4 Réponses :
faire une initialisation statique comme dans votre premier bloc de code couple sur la nécessité d'une vérification null, et si vous savez que vous utiliserez la collection dans la majorité des cas d'utilisation, c'est logique.
Si, d'autre part, la collection est rarement utilisée, il est plus logique de différer l'initialisation jusqu'à ce que vous ayez besoin de l'utiliser.
Vous devriez l'initialiser. Même si hibernez-le où l'initialisez-le plus tard, même s'il n'avait pas de contenu (ce que je ne suis pas sûr que ce soit toujours le cas), vous devriez l'initialiser pour être sûr qu'il est toujours cohérent non-null.
Dans l'exemple fourni, vous pouvez voir que le chat n'a pas de constructeur sans argument explicite, de sorte qu'ils ont initialiser l'ensemble de la déclaration. Très probablement lorsque vous voyez qu'il est laissé ininitialisé, il y avait aussi un constructeur de no-argplicité qui l'initialise plus tard.
"Vous cherchez une réponse à partir de sources crédibles et / ou officielles."
Je ne peux pas sauvegarder avec une sorte de documentation professionnelle, mais voici mon opinion à ce sujet. Je pense que vous avez deux routes possibles à suivre.
Le premier fort> repose sur des haricots modèles pour être un dtos ordinaire, utilisé uniquement Pour la persistance des données, n'effectuez aucune logique. Ici, vous pouvez classes de modèle appropriées strong> p> La deuxième approche prend des pojos un peu plus loin. Dans ce scénario, vous pouvez effectuer une certaine logique dans les méthodes Getters et Setters. Ce n'est pas que le scénario peu commun, après tout, il est parfaitement acceptable par MVC et très souvent, on se trouverait besoin d'ajouter un code à eux. Par exemple - Connexion des informations lors de l'appelant Setter Méthode, Exemple ci-dessous: P> public void setItems(List<Object> items){
LOGGER.info("Setting '{}' new items", items.size());
this.items = items;
}
de Hibernate's Collection persistante Documentation:
En raison du modèle relationnel sous-jacent, les propriétés de la collecte-valorisées ne supportent pas la sémantique de la valeur null. Hibernate ne distingue pas une référence de collection nulle et une collection vide.
et ...
Lorsque vous faites l'instance persistante, en appelant persist (), Hibernate remplacera effectivement le hashset avec une instance de la mise en œuvre propre de Hibernate de l'ensemble.
Ces "collection non nulle" et la sémantique "persistante" par rapport à "non persistante" se perdent parfois avec les développeurs. Pour garder les choses simples avec des objets hibernés, je préfère:
- Initialise toujours tous les collections
avecjava.util implémentations- TOUJOURS CODE TO
COLLECTION Interfacesrendant le rendement habituel pour l'objet Hibernate
S n'est jamais nul et d'éviter le piège indiqué dans la documentation ci-dessus de casting d'un objet hibernatecollection à une implémentation non valide.
Par 'Collection d'instance' signifie-tu "propriété de collection persistante"?
@MikePartridge Oui, c'est ce que je voulais dire.