Figure 3-10. SpringBlog application's layered architecture
Having discussed the layered architecture, let's look at how each layer will be implemented in the
SpringBlog application.
Implementing the Persistence Layer
Data access is a topic close to many developers' hearts, and it is often the subject of many heated
discussions on developer forums across the Internet. In recent times, the focus in the Java world has
been on object-relational mapping (ORM) tools as a replacement for JDBC, which many see as an
overcomplicated mess. A big part of Spring's feature set lies in its support for data access technologies.
All in all, Spring supports several different data access mechanisms: plain JDBC, Hibernate, MyBatis
(iBATIS), Java Data Objects (JDO), and JPA.
With the SpringBlog application, we wanted to show how easy it is to switch between data access
implementations, so we built two different implementations of the persistence layer, one using JPA
(using Hibernate as the underlying persistence service provider) and the other using MyBatis.
Hibernate is perhaps the most well-known ORM tool in the Java world, and it has enjoyed a great
success because of the ease with which it can be used to develop high-performance persistence logic.
Although Hibernate has quite a simple API, the error-handling code you need to use Hibernate is quite
verbose; Spring simplifies this greatly, reducing most Hibernate operations to just a single line of code.
Also, because of the significant success ORM tools like Hibernate have achieved and Hibernate's wide
acceptance by developers for data access, JCP has formulized the technology into JEE's technology stack.
Starting from EJB 3.0, the entity bean specification has been replaced by the Java Persistence API (JPA).
Currently at version 2.0, JPA is part of the JEE 6 standard and has incorporated many ideas from popular
Search WWH :
