Better Faster Lighter Java [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Better Faster Lighter Java [Electronic resources] - نسخه متنی

Justin Gehtland; Bruce A. Tate

نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
تنظیمات قلم


اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
لیست موضوعات
افزودن یادداشت
افزودن یادداشت جدید

10.6 Adding Hibernate

jPetStore uses a relatively

straightforward architecture for providing
database access. There is an interface layer that provides functional
mapping to the DAOs themselves without worrying about actual
implementation details. The specific DAOs vary based on the backend
database; we'll be examining the ones targeting
HSQLDB (Hypersonic SQL).

10.6.1 Existing Architecture

Let's look at how the Product
class is managed. Product is the domain object
that represents one item in the catalog.

package org.springframework.samples.jpetstore.domain;
public class Product implements Serializable {
private String productId;
private String categoryId;
private String name;
private String description;
public String getProductId( ) { return productId; }
public void setProductId(String productId) { this.productId = productId.trim( ); }
public String getCategoryId( ) { return categoryId; }
public void setCategoryId(String categoryId) { this.categoryId = categoryId; }
public String getName( ) { return name; }
public void setName(String name) { = name; }
public String getDescription( ) { return description; }
public void setDescription(String description) { this.description = description;}
public String toString( ) {
return getName( );

Its persistence is managed through an object that implements the
ProductDao interface. A
ProductDao must be able to load a specific product
given its ID, or load a list of products either from a category or
from a set of keywords.

public interface ProductDao {
List getProductListByCategory(String categoryId) throws DataAccessException;
List searchProductList(String keywords) throws DataAccessException;
Product getProduct(String productId) throws DataAccessException;

There currently exists a class called
SqlMapProductDao that looks up product information
in Hypersonic SQL through SQL mapping files.

10.6.2 Hibernate Mappings for Existing Domain Objects

To replace this architecture with one based on Hibernate, we first
have to create mapping files that define the relationship between the
domain objects and the database. Looking again at
Product, we'll create a mapping
file called Product.hbm.xml which looks like:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 2.0//EN"
<class name="Product" table="product">
<id name="productId"
<generator class="native"/>
<property name="categoryId" column="category" type="string"/>
<property name="name" column="name" type="string"/>
<property name="description" column="description" type="string"/>

In the mapping file, we first identify the package and particular
that we are mapping. We have to tell it what table to map to
("product", in this case) and then map the
individual properties of the domain object to the columns in the
table. This file needs to be saved somewhere on the class path;
we'll create a new folder in the project structure
called "hibernate" to hold our map
files and our new DAOs.

10.6.3 Hibernate DAOs

The next step is to create a DAO that uses Hibernate as the
persistence layer instead of the SQL mappings used in the original
version. The new DAO needs to implement the
ProductDao interface, just like the original DAO.
However, the implementation of that interface will be totally

Here is the code for the new DAO:

public class HibernateProductDao implements ProductDao {
SessionFactory factory;
Configuration cfg;
public HibernateProductDao( ) {
try {
cfg = new Configuration( ).addClass(
factory = cfg.buildSessionFactory( );
} catch (Exception ex) {
System.out.println("Hibernate configuration failed: " + ex);
public List getProductListByCategory(String categoryId)
throws DataAccessException {
List results = null;
try {
Session session = factory.openSession( );
results = session.find("from product where product.category = ?",
categoryId, Hibernate.STRING);
session.close( );
} catch (Exception ex) {
System.out.println("Failed to connect to database:" + ex);
return results;
public List searchProductList(String keywords) throws DataAccessException {
return null;
public Product getProduct(String productId) throws DataAccessException {
Product p = null;
try {
Session session = factory.openSession( );
p = (Product)session.load(Product.class, productId);
session.close( );
} catch (Exception ex) {
System.out.println("failed to connect to database: " + ex);
p = null;
return p;

First, we need a way to interact with Hibernate. As shown in Chapter 7, we need to create a Hibernate
SessionFactory and use it to get a
Session with which to interact with the database.
The DAO's constructor instantiates a new Hibernate
configuration, loading the mapping file from the class path based on
the name of the class added to the configuration. Then, it gets the
SessionFactory from the Configuration.

Each method uses the SessionFactory to open a new
Session with the database. The
getProduct method is the most straightforward;
first, we get the Session. Then, we ask the session to load an
instance of the Product class, given its
productId. Note that the result from the session.load(
call is of type Object, which we have
to cast to Product. Finally, we close the Session. Hibernate handles
all the SQL commands, looking up the mapping files, matching the
productId to the right column in the table, populating all the
fields, everything.

The getProductListByCategory( ) method is less
straightforward; it takes a categoryId and returns
a List of all the products that match that category. In this case, we
can't rely on the built-in SQL generation; we have
to create our own query. Again, we first grab a
Session from the
SessionFactory, then use the
session.find( ) method, which returns a
List of Objects. Find takes
three parameters in this case: the HSQL query (which contains a
placeholder for a query parameter, marked with a
"?"), the value to fill into the
query parameter, and the type of that parameter.

As shown in Chapter 7, HSQL (Hibernate SQL)
queries look a lot like regular SQL statements, except here we left
off the "SELECT [values]" part of
the statement, since Hibernate will fill those in for us based on the
mapping. This method will now look up all the rows in the Product
table where categoryId equals the value passed in
to the method, and create one instance of Product
for each row in the resultset. All the product instances are placed
in a List and returned.

The final method of the DAO, searchProductList,
would be a lot more complex, but luckily, we don't
have to implement it. Since we have already replaced the original
search functionality with the Simple Spider, this method will never
be called now, so we simply return null (we have
to do something, since the ProductDao interface
still mandates its inclusion).

To finish out the new architecture, we just repeat these steps for
each of the remaining five domain objects. Each gets a mapping file
and an implementation of the appropriate DAO interface.

10.6.4 Changing the Application Configuration

In order to get the new DAOs working with
jPetStore, we need to modify some configuration
files. First, we'll need to create the global file, which tells Hibernate
which database to use and how to use it. jPetStore
is currently configured to use a local instance of Hypersonic SQL,
with a username of "sa" and a blank
password (NEVER do this in a production environment). The file looks like this:

hibernate.connection.driver_class = org.hsqldb.jdbcDriver
hibernate.connection.url = jdbc:hsqldb:hsql://localhost:9002
hibernate.connection.username = sa
hibernate.connection.password =

This file should be saved in the project root file, next to the other
global configuration files. Hibernate will look for it by name.

Next, open up jPetStore's
dataAccessContext-*.xml files (one is
dataAccessContext-jta.xml and the other is
<property name="dataSource"><ref local="dataSource"/></property>
<property name="sqlMap"><ref local="sqlMap"/></property>

This now becomes:

<bean id="productDao" class="org.springframework.samples.jpetstore.dao.hibernate.

We can eliminate the properties because the Hibernate versions of the
DAOs do not require any configuration information to be passed in by
the controller; Hibernate manages those issues for us.

Once you have successfully changed all the DAO references, the last
remaining piece is to include the necessary jar
files in your class path. Hibernate requires the following
jars: hibernate2.jar,
cglib2.jar, ehcache.jar,
dom4j.jar, and jta.jar (all
of which are included in the Hibernate download).

10.6.5 Spring's Built-In Hibernate Support

Now that you have seen the explicit way to do things,
let's briefly take a look at the supporting
infrastructure Spring provides for Hibernate. Spring, through its
"inversion of control"
architecture, can fully manage the creation of the
SessionFactory for you. In addition, it provides a
new class, HibernateDaoSupport, which allows your
application-specific DAOs to reuse standard, template-derived calls
for interacting with the datasource.

To set it up, you need to change your DAOs to extend
HibernateDaoSupport. So, this:

public class HibernateProductDao implements ProductDao


public class HibernateProductDao extends HibernateDaoSupport implements ProductDao

Then add the following code to enable Spring to pass in a

private SessionFactory sessionFactory;
public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;

After adding this, your DAOs can use an object provided by
HibernateDaoSupport called
HibernateTemplate. This new class, accessed
through the new getHibernateTemplate( ) method
inherited from HibernateDaoSupport, exposes a
series of helper methods for interacting with the database, such as
load, save,
update, saveOrUpdate,
get, and find. Our
ProductDao becomes a lot simpler:

public class HibernateProductDao extends HibernateDaoSupport implements ProductDao {
private SessionFactory sessionFactory;
public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;
public HibernateProductDao( ) {
public List getProductListByCategory(String categoryId) {
return getHibernateTemplate( ).find("from product where product.category = ?",
categoryId, Hibernate.STRING);
public List searchProductList(String keywords) throws DataAccessExcetption {
return null;
public Product getProduct(String ProductID) throws DataAccessException {
return (Product) getHibernateTemplate( ).load(Product.class, productId);

To configure all of this, you'll have to make some
changes to your configuration files. You now have to add a property
for the SessionFactory where you defined the
ProductDao bean:

<bean id="productDao"
<property name="sessionFactory"/>
<ref bean="mySessionFactory"/>

Then add a definition of the mySessionFactory bean:

<bean id="mySessionFactory"
<property name="mappingResources">
<!-- etc. -->
<property name="hibernateProperties">
<prop key="hibernate.dialect">net.sf.hibernate.dialect.HSQLDialect</prop>
<property name="dataSource">
<ref bean="dataSource"/>

Add as many entries to the mappingResources
property as you have map files, and make sure
that the dataSource property refers to your
already-configured dataSource bean. With these
minimal changes, your DAOs become much more standardized and
compacted, and Spring handles all your
SessionFactory and Session
implementation details for you. You are free to focus, yet again, on
the problem at hand rather than the supporting framework.

That's it! Once again, we've
managed to replace an entire swath of existing code without touching
the original codebase itself. We have simply added new classes to the
project and changed some configuration settings, and voila!

10.6.6 Principles in Action

Keep it simple: domain objects remain unaware of persistence logic,
Hibernate manages all configuration

Choose the right tools: Hibernate

Do one thing, and do it well: the domain model is focused on the
business problem, the DAOs focus on data manipulation and are

Strive for transparency: domain model is completely unaware of
persistence layer

Allow for extension: Spring configuration

and IoC allow us
to change persistence layers

/ 111