One of the key features of Hibernate’s design is the principle of least intrusiveness—the Hibernate developers did not want Hibernate to intrude into your application more than was necessary. This led to several of the architectural decisions made for Hibernate.
Hibernate can be configured to run in almost any Java application and development environment. Generally, Hibernate is used in two- and three-tiered client/server applications, with Hibernate deployed only on the server.
5 main Hibernate interfaces you will use:
- Session
The Session interface is the primary interface used by Hibernate applications.
The Hibernate notion of a session is something between connection and transaction.
It may be easier to think of a session as a cache or collection of loaded objects relating to a single unit of work.
We sometimes call the Session a persistence manager because it’s also the interface for persistence-related operations such as storing and retrieving objects.
Note that a Hibernate session has nothing to do with the web-tier HttpSession. - SessionFactory
The application obtains Session instances from a SessionFactory.
There is typically a single SessionFactory for the whole application—created during application initialization, for example. However, if your application accesses multiple databases using Hibernate, you’ll need a SessionFactory for each database.
The SessionFactory caches generated SQL statements and other mapping metadata that Hibernate uses at runtime. - Configuration
The Configuration object is used to configure and bootstrap Hibernate. The application uses a Configuration instance to specify the location of mapping documents and Hibernate-specific properties and then create the SessionFactory.
Even though the Configuration interface plays a relatively small part in the total scope of a Hibernate application, it’s the first object you’ll meet when you begin using Hibernate. - Transaction interface
The Transaction interface is an optional API. Hibernate applications may choose not to use this interface, instead managing transactions in their own infrastructure code. - Query and Criteria interfaces
The Query interface allows you to perform queries against the database and control how the query is executed. A Query instance is used to bind query parameters, limit the number of results returned by the query, and finally to execute the query.
The Criteria interface is very similar; it allows you to create and execute objectoriented criteria queries.
Callback interfaces
Callback interfaces allow the application to receive a notification when something interesting happens to an object—for example, when an object is loaded, saved, or deleted. Hibernate applications don’t need to implement these callbacks, but they’re useful for implementing certain kinds of generic functionality, such as creating audit records.
Types
A fundamental and very powerful element of the architecture is Hibernate’s notion of a Type. A Hibernate Type object maps a Java type to a database column type (actually, the type may span multiple columns). All persistent properties of persistent classes, including associations, have a corresponding Hibernate type.
This design makes Hibernate extremely flexible and extensible. There is a rich range of built-in types, covering all Java primitives and many JDK classes, including types for java.util.Currency, java.util.Calendar, byte[], and java.io.Serializable.
Extension interfaces
Much of the functionality that Hibernate provides is configurable, allowing you to choose between certain built-in strategies. When the built-in strategies are insufficient, Hibernate will usually let you plug in your own custom implementation by implementing an interface.
Extension points include:
- Primary key generation (IdentifierGenerator interface)
- SQL dialect support (Dialect abstract class)
- Caching strategies (Cache and CacheProvider interfaces)
- JDBC connection management (ConnectionProvider interface)
- Transaction management
Hibernate ships with at least one implementation of each of the listed interfaces, so you don’t usually need to start from scratch if you wish to extend the built-in functionality. The source code is available for you to use as an example for your own implementation.