Bonne nuit, Habr.
Cet article est une tentative de faciliter la recherche de personnes commençant en hibernation et confrontées à la même question que moi - savoir
comment écrire correctement sur cet outil . (Cela sera particulièrement utile pour les programmeurs qui viennent en Java à partir de langages faiblement typés). Il n'y aura pas de code, il y aura des principes de base sur la façon d'utiliser cette technologie de manière productive. Tout ce qui est écrit sous la coupe est mon IMHO, ne revendiquant pas la seule solution possible au problème.
Alors
Faites immédiatement une réservation que mon expérience a été avec
Spring Data JPA .
Hibernate étant un framework d'entreprise, il est difficile de trouver des exemples de code plus profond que CRUD classique. Ce fait complique sérieusement la compréhension de la façon d'écrire dans Hiber, comment les développeurs du framework eux-mêmes ont imaginé du bon code - en conséquence, j'ai dû penser à ce problème moi-même. Je suis sûr que je ne suis pas seul.
@
La première chose que vous pouvez remarquer est qu'il n'y a pas de base de données en tant qu'abstraction. En veille prolongée, tout a été fait pour obtenir un contrôle total sur la base de données dans le code (vous pouvez google Entity Management). Votre base de données est constituée d'objets de domaine qui remplissent la fonction de stockage presque stupide. D'où une règle importante: ne les utilisez que pour le stockage. Ils ne doivent pas exécuter les fonctions d'un DTO qui accepte les entrées de l'utilisateur et ne doivent pas servir d'affichage pendant la sérialisation. Ils ont des pattes.
Incroyable mais vraiEn général, il est surprenant que je n'ai pas vu dans le segment éducatif d'Internet (y compris l'anglais) un exemple d'utilisation de classes supplémentaires pour la sérialisation, par exemple, en json. Qui a déjà dit que si vous avez un service REST, vous n'avez pas à vous soucier des classes d'affichage?)
Oui, et pas pour REST, l'intuition suggère que sur un bon ton, il ne donnera au client que l'ensemble de données dont il a besoin, tandis que toutes les données sont prêtes (et n'ont pas eu à appeler des getters sur le client pour une initialisation paresseuse).
@
Cela implique la règle suivante - ils ne devraient pas se soucier du format d'utilisation. Que nous ayons besoin d'une liste de produits (où seuls le nom et la description seront) ou d'une page de produit (avec photos et avis) - le client recevra dans un cas une
List de
SimpleProductViewer (id, name, description) , et dans l'autre
ExtendedProductViewer (id, name, description, List(photos), List(reviews), rating) , qui seront générés dans les méthodes de la classe
ProductService et utiliser les classes de domaine
uniquement comme source de données.
Même chose avec entrée. C'est Java, ici c'est ok de faire du DTO avec des champs différents pour chaque cas :)
À titre d'exemple, je vais augmenter la base de classe pour le domaine Produit hackneyed. Ce que nous avons déjà:
- Produit (domaine)
- Visionneuse (classes pour l'affichage des informations par le client, peut être n'importe quel nombre)
- Dto (les classes pour obtenir des informations peuvent également être de n'importe quel nombre)
- Référentiel (pour recevoir des données)
- Service (ou Manager) - une boîte noire pour la logique métier non contrôlée, qui combine tous les points précédents.
@
Il me semble (semble-t-il) que Java Enterprise n'est pas très optimisé (cela se voit déjà à la demande de hibernate et du fait même que OOP (hibernate) a pris le relais pour la gestion des entités de base de données). Par conséquent, je pense que l'essentiel dans ce contexte est la correspondance du code avec les idées des développeurs du framework, et non la stratégie optimale.
@
Si vous regardez les domaines d'hibernation de cette manière (uniquement le stockage de données),
@ManyToOne semble être un mécanisme qui n'est pas si souvent utilisé et ne s'applique qu'aux tableaux complètement dépendants - images, critiques, commentaires. En principe, cela est normal - à mon avis, il n'est pas nécessaire d'étendre leur effet aux tables de base de votre base de données.
Résumer
- Utilisez le domaine uniquement pour le stockage de données, il est souhaitable que les propriétés de la classe soient contenues dans la table de base de données cible, c'est-à-dire qu'il n'y a rien de superflu (dicté par la logique métier).
- Pas besoin d'essayer d'étendre le domaine - étendez les classes d'affichage et utilisez les classes de domaine uniquement en tant que fournisseur de données.
- N'ayez pas peur de produire le même type de classes - la compréhensibilité et la flexibilité d'utilisation sont plus importantes. Le maximum qui peut être fait pour réduire la quantité de code est de les hériter du domaine.
- Ne poursuivez pas l'optimisation. Pour les garçons java, ce n'est pas important, même si, bien sûr, tout dépend du contexte.
Quelque chose comme ça.