Voici une vue (très) haut niveau de l'architecture d'Hibernate :
Ce diagramme montre Hibernate utilisant une base de données et des données de configuration pour fournir un service de persistance (et des objets persistants) à l'application.
Nous aimerions décrire une vue plus détaillée de l'architecture. Malheureusement, Hibernate est flexible et supporte différentes approches. Nous allons en montrer les deux extrêmes. L'architecture légère laisse l'application fournir ses propres connexions JDBC et gérer ses propres transactions. Cette approche utilise le minimum des APIs Hibernate :
L'architecture la plus complète abstrait l'application des APIs JDBC/JTA sous-jacentes et laisse Hibernate s'occuper des détails.
Heres some definitions of the objects in the diagrams:
- SessionFactory (
org.hibernate.SessionFactory) -
Un cache threadsafe (immuable) des mappings vers une (et une seule) base de données. Une factory (fabrique) de
Sessionet un client deConnectionProvider. Peut contenir un cache optionnel de données (de second niveau) qui est réutilisable entre les différentes transactions que cela soit au sein du même processus (JVLM) ou par plusieurs nœuds d'un cluster. - Session (
org.hibernate.Session) -
Un objet mono-threadé, à durée de vie courte, qui représente une conversation entre l'application et l'entrepôt de persistance. Encapsule une connexion JDBC. Factory (fabrique) des objets
Transaction. Contient un cache (de premier niveau) des objets persistants, ce cache est obligatoire. Il est utilisé lors de la navigation dans le graphe d'objets ou lors de la récupération d'objets par leur identifiant. - Objets et Collections persistants
-
Objets mono-threadés à vie courte contenant l'état de persistance et la fonction métier. Ceux-ci sont en général les objets de type JavaBean (ou POJOs) ; la seule particularité est qu'ils sont associés avec une (et une seule)
Session. Dès que laSessionest fermée, ils seront détachés et libres d'être utilisés par n'importe laquelle des couches de l'application (ie. de et vers la présentation en tant que Data Transfer Objects - DTO : objet de transfert de données). - Objets et collections transients
-
Instances de classes persistantes qui ne sont actuellement pas associées à une
Session. Elles ont pu être instanciées par l'application et ne pas avoir (encore) été persistées ou elle ont pu être instanciées par uneSessionfermée. - Transaction (
org.hibernate.Transaction) -
(Optionnel) Un objet mono-threadé à vie courte utilisé par l'application pour définir une unité de travail atomique. Abstrait l'application des transactions sous-jacentes qu'elles soient JDBC, JTA ou CORBA. Une
Sessionpeut fournir plusieursTransactions dans certains cas. Toutefois, la délimitation des transactions, via l'API d'Hibernate ou par laTransactionsous-jacente, n'est jamais optionnelle! - ConnectionProvider (
org.hibernate.connection.ConnectionProvider) -
(Optionnel) Une fabrique de (pool de) connexions JDBC. Abstrait l'application de la
Datasourceou duDriverManagersous-jacent. Non exposé à l'application, mais peut être étendu/implémenté par le développeur. - TransactionFactory (
org.hibernate.TransactionFactory) -
(Optionnel) Une fabrique d'instances de
Transaction. Non exposé à l'application, mais peut être étendu/implémenté par le développeur. - Interfaces d'extension
-
Hibernate fournit de nombreuses interfaces d'extensions optionnelles que vous pouvez implémenter pour personnaliser le comportement de votre couche de persistance. Reportez vous à la documentation de l'API pour plus de détails.
Dans une architecture légère, l'application n'aura pas à utiliser les APIs Transaction/TransactionFactory et/ou n'utilisera pas les APIs ConnectionProvider pour utiliser JTA ou JDBC.