Hibernate is an open source object/relational mapping tool for Java environments. The aim of hibernate is to remove the majority of the drudgery and time consuming repetitive coding. Mapping means Java classes to database tables is accomplished through the configuration of an XML file or by using Java Annotations. The term object/relational mapping (ORM) refers to the technique of mapping a data representation from an object model to a relational data model with a SQL-based schema. Hibernate supports many different relational databases. Many other open source tools use Hibernate as their persistence layer. Hibernate includes tools to make O/R persistence (that is at least form the point of view of the object being persisted) an integrated part of the build process.
Hibernate supports the mapping of custom value types. The following scenarios are possible
- Overriding the default SQL type that Hibernate chooses when mapping a column to a property.
- Mapping java Enum to columns as if they were regular properties.
- Mapping a single property to multiple columns.
- Mapping one to one or one to many entities.
We can use spring framework to create our ORM DAOs. The benefits of using the spring framework are,
1) Ease of testing: – Spring’s IoC helps to easy to swap the implementations and config locations of Hibernate SessionFactory instances, JDBC DataSource instances, transaction managers, and mapper object implementations. It makes easier to isolate and test each piece of persistence-related code in isolation.
2) Common data access exception: – Spring can cover exceptions from our O/R mapping tool of choice, converting them from proprietary (potentially checked) exceptions to a common runtime DataAccessException hierarchy. This permits to handle most persistence exceptions, which are non-recoverable, only in the appropriate layers, without annoying boilerplate catches/throws, and exception declarations. We can still trap and handle exceptions anywhere we need to. The JDBC exceptions (including DB specific dialects) are also converted to the same hierarchy, meaning that you can perform some operations with JDBC within a consistent programming model.
3) General resource management: – Spring application context helps to handle the location and configuration of Hibernate SessionFactory instances, JDBC DataSource instances, iBATIS SQL Maps configuration objects, and other related resources. It helps the values easy to manage and change and gives efficient, easy and safe handling of persistence resources.
Eg: – The related code needs to use the same Hibernate Session for efficiency and proper transaction handling. Spring makes it easy to transparently create and bind a Session to the current thread, either by using an explicit ‘template’ wrapper class at the Java code level or by exposing a current Session through the Hibernate SessionFactory (for DAOs based on plain Hibernate API). Thus spring resolves number of the issues that repeatedly arise from typical Hibernate usage, for any transaction environment (local or JTA).
4) Integrated transaction management: – Spring permits to cover your O/R mapping code with either a declarative, AOP style method interceptor, or an explicit ‘template’ wrapper class at the Java code level. In either case, transaction semantics are handled for you, and proper transaction handling (rollback, etc) in case of exceptions is taken care of. Also gets the benefit of being able to use and swap various transaction managers, without your Hibernate/JDO related code being affected:
Eg: – Between local transactions and JTA, with the same full services (such as declarative transactions) available in both scenarios. As an additional benefit, JDBC-related code can fully integrate transactionally with the code you use to do O/R mapping. This is useful for data access that’s not suitable for O/R mapping, such as batch processing or streaming of BLOBs, which still needs to share common transactions with ORM operations