<转>Generic Data Access Objects

Generic Data Access Objects
http://www.hibernate.org/328.html
...dao的设计,与数据库打交道都需要吧
 
The DAO interfaces
An implementation with Hibernate
Preparing DAOs with factories
Preparing DAOs with manual dependency injection
Preparing DAOs with lookup
Writing DAOs as managed EJB 3.0 components
This is a pattern for Data Access Objects with JDK 5.0, from the CaveatEmptor example application. It is also explained in the book Java Persistence with Hibernate. Two links you might find useful: Sessions and transactions and Open Session in View.

This time I based the DAO example on interfaces. Tools like Hibernate already provide database portability, so persistence layer portability shouldn't be a driving motivation for interfaces. However, DAO interfaces make sense in more complex applications, when several persistence services are encapsulate in one persistence layer. I'd say that you should use Hibernate (or Java Persistence APIs) directly in most cases, the best reason to use an additional DAO layer is higher abstraction (e.g. methods like getMaximumBid() instead of session.createQuery(...) repeated a dozen times).

The DAO interfaces
I use one interface per persistent entity, with a super interface for common CRUD functionality:

public interface GenericDAO {

    T findById(ID id, boolean lock);

    List findAll();

    List findByExample(T exampleInstance);

    T makePersistent(T entity);

    void makeTransient(T entity);
}

You can already see that this is going to be a pattern for a state-oriented data access API, with methods such as makePersistent() and makeTransient(). Furthermore, to implement a DAO you have to provide a type and an identifier argument. As for most ORM solutions, identifier types have to be serializable.

The DAO interface for a particular entity extends the generic interface and provides the type arguments:

public interface ItemDAO extends GenericDAO {

    public static final String QUERY_MAXBID = "ItemDAO.QUERY_MAXBID";
    public static final String QUERY_MINBID = "ItemDAO.QUERY_MINBID";

    Bid getMaxBid(Long itemId);
    Bid getMinBid(Long itemId);

}

We basically separate generic CRUD operations and actual business-related data access operations from each other. (Ignore the named query constants for now, they are convenient if you use annotations.) However, even if only CRUD operations are needed for a particular entity, you should still write an interface for it, even it it is going to be empty. It is important to use a concrete DAO in your controller code, otherwise you will face some refactoring once you have to introduce specific data access operations for this entity.

An implementation with Hibernate
An implementation of the interfaces could be done with any state-management capable persistence service. First, the generic CRUD implementation with Hibernate:

public abstract class GenericHibernateDAO
        implements GenericDAO {

    private Class persistentClass;
    private Session session;

    public GenericHibernateDAO() {
        this.persistentClass = (Class) ((ParameterizedType) getClass()
                                .getGenericSuperclass()).getActualTypeArguments()[0];
     }

    @SuppressWarnings("unchecked")
    public void setSession(Session s) {
        this.session = s;
    }

    protected Session getSession() {
        if (session == null)
            throw new IllegalStateException("Session has not been set on DAO before usage");
        return session;
    }

    public Class getPersistentClass() {
        return persistentClass;
    }

    @SuppressWarnings("unchecked")
    public T findById(ID id, boolean lock) {
        T entity;
        if (lock)
            entity = (T) getSession().load(getPersistentClass(), id, LockMode.UPGRADE);
        else
            entity = (T) getSession().load(getPersistentClass(), id);

        return entity;
    }

    @SuppressWarnings("unchecked")
    public List findAll() {
        return findByCriteria();
    }

    @SuppressWarnings("unchecked")
    public List findByExample(T exampleInstance, String[] excludeProperty) {
        Criteria crit = getSession().createCriteria(getPersistentClass());
        Example example =  Example.create(exampleInstance);
        for (String exclude : excludeProperty) {
            example.excludeProperty(exclude);
        }
        crit.add(example);
        return crit.list();
    }

    @SuppressWarnings("unchecked")
    public T makePersistent(T entity) {
        getSession().saveOrUpdate(entity);
        return entity;
    }

    public void makeTransient(T entity) {
        getSession().delete(entity);
    }

    public void flush() {
        getSession().flush();
    }

    public void clear() {
        getSession().clear();
    }

    /**
     * Use this inside subclasses as a convenience method.
     */
    @SuppressWarnings("unchecked")
    protected List findByCriteria(Criterion... criterion) {
        Criteria crit = getSession().createCriteria(getPersistentClass());
        for (Criterion c : criterion) {
            crit.add(c);
        }
        return crit.list();
   }

}

There are some interesting things in this implementation. First, it clearly needs a Session to work, provided with setter injection. You could also use constructor injection. How you set the Session and what scope this Session has is of no concern to the actual DAO implementation. A DAO should not control transactions or the Session scope.

We need to suppress a few compile-time warnings about unchecked casts, because Hibernate's interfaces are JDK 1.4 only. What follows are the implementations of the generic CRUD operations, quite straightforward. The last method is quite nice, using another JDK 5.0 feature, varargs. It helps us to build Criteria queries in concrete entity DAOs. This is an example of a concrete DAO that extends the generic DAO implementation for Hibernate:

public class ItemDAOHibernate
        extends     GenericHibernateDAO
        implements  ItemDAO {

    public Bid getMaxBid(Long itemId) {
        Query q = getSession().getNamedQuery(ItemDAO.QUERY_MAXBID);
        q.setParameter("itemid", itemId);
        return (Bid) q.uniqueResult();
    }

    public Bid getMinBid(Long itemId) {
        Query q = getSession().getNamedQuery(ItemDAO.QUERY_MINBID);
        q.setParameter("itemid", itemId);
        return (Bid) q.uniqueResult();
    }

}

Another example which uses the findByCriteria() method of the superclass with variable arguments:

public class CategoryDAOHibernate
        extends     GenericHibernateDAO
        implements  CategoryDAO {

    public Collection findAll(boolean onlyRootCategories) {
        if (onlyRootCategories)
            return findByCriteria( Expression.isNull("parent") );
        else
            return findAll();
    }
}

Preparing DAOs with factories
We could bring it all together in a DAO factory, which not only sets the Session when a DAO is constructed but also contains nested classes to implement CRUD-only DAOs with no business-related operations:

public class HibernateDAOFactory extends DAOFactory {

    public ItemDAO getItemDAO() {
        return (ItemDAO)instantiateDAO(ItemDAOHibernate.class);
    }

    public CategoryDAO getCategoryDAO() {
        return (CategoryDAO)instantiateDAO(CategoryDAOHibernate.class);
    }

    public CommentDAO getCommentDAO() {
        return (CommentDAO)instantiateDAO(CommentDAOHibernate.class);
    }

    public ShipmentDAO getShipmentDAO() {
        return (ShipmentDAO)instantiateDAO(ShipmentDAOHibernate.class);
    }

    private GenericHibernateDAO instantiateDAO(Class daoClass) {
        try {
            GenericHibernateDAO dao = (GenericHibernateDAO)daoClass.newInstance();
            dao.setSession(getCurrentSession());
            return dao;
        } catch (Exception ex) {
            throw new RuntimeException("Can not instantiate DAO: " + daoClass, ex);
        }
    }

    // You could override this if you don't want HibernateUtil for lookup
    protected Session getCurrentSession() {
        return HibernateUtil.getSessionFactory().getCurrentSession();
    }

    // Inline concrete DAO implementations with no business-related data access methods.
    // If we use public static nested classes, we can centralize all of them in one source file.

    public static class CommentDAOHibernate
            extends GenericHibernateDAO
            implements CommentDAO {}

    public static class ShipmentDAOHibernate
            extends GenericHibernateDAO
            implements ShipmentDAO {}

}

This concrete factory for Hibernate DAOs extends the abstract factory, which is the interface we'll use in application code:

public abstract class DAOFactory {

    /**
     * Creates a standalone DAOFactory that returns unmanaged DAO
     * beans for use in any environment Hibernate has been configured
     * for. Uses HibernateUtil/SessionFactory and Hibernate context
     * propagation (CurrentSessionContext), thread-bound or transaction-bound,
     * and transaction scoped.
     */
    public static final Class HIBERNATE = org.hibernate.ce.auction.dao.hibernate.HibernateDAOFactory.class;

    /**
     * Factory method for instantiation of concrete factories.
     */
    public static DAOFactory instance(Class factory) {
        try {
            return (DAOFactory)factory.newInstance();
        } catch (Exception ex) {
            throw new RuntimeException("Couldn't create DAOFactory: " + factory);
        }
    }

    // Add your DAO interfaces here
    public abstract ItemDAO getItemDAO();
    public abstract CategoryDAO getCategoryDAO();
    public abstract CommentDAO getCommentDAO();
    public abstract ShipmentDAO getShipmentDAO();

}

Note that this factory example is suitable for persistence layers which are primarily implemented with a single persistence service, such as Hibernate or EJB 3.0 persistence. If you have to mix persistence APIs, for example, Hibernate and plain JDBC, the pattern changes slightly. Keep in mind that you can also call session.connection() inside a Hibernate-specific DAO, or use one of the many bulk operation/SQL support options in Hibernate 3.1 to avoid plain JDBC.

Finally, this is how data access now looks like in controller/command handler code (pick whatever transaction demarcation strategy you like, the DAO code doesn't change):

// EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED)
public void execute() {

    // JTA: UserTransaction utx = jndiContext.lookup("UserTransaction");
    // JTA: utx.begin();

    // Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction();

    DAOFactory factory = DAOFactory.instance(DAOFactory.HIBERNATE);
    ItemDAO itemDAO = factory.getItemDAO();
    UserDAO userDAO = factory.getUserDAO();

    Bid currentMaxBid = itemDAO.getMaxBid(itemId);
    Bid currentMinBid = itemDAO.getMinBid(itemId);

    Item item = itemDAO.findById(itemId, true);

    newBid = item.placeBid(userDAO.findById(userId, false),
                            bidAmount,
                            currentMaxBid,
                            currentMinBid);

    // JTA: utx.commit(); // Don't forget exception handling

    // Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling

}

The database transaction, either JTA or direct JDBC, is started and committed in an interceptor that runs for every execute(), following the Open Session in View pattern. You can use AOP for this or any kind of interceptor that can be wrapped around a method call, see Session handling with AOP.

Preparing DAOs with manual dependency injection
You don't need to write the factories. You can as well just do this:

// EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED)
public void execute() {

    // JTA: UserTransaction utx = jndiContext.lookup("UserTransaction");
    // JTA: utx.begin();

    // Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction();

    ItemDAOHibernate itemDAO = new ItemDAOHibernate();
    itemDAO.setSession(HibernateUtil.getSessionFactory().getCurrentSession());

    UserDAOHibernate userDAO = new UserDAOHibernate();
    userDAO.setSession(HibernateUtil.getSessionFactory().getCurrentSession());

    Bid currentMaxBid = itemDAO.getMaxBid(itemId);
    Bid currentMinBid = itemDAO.getMinBid(itemId);

    Item item = itemDAO.findById(itemId, true);

    newBid = item.placeBid(userDAO.findById(userId, false),
                            bidAmount,
                            currentMaxBid,
                            currentMinBid);

    // JTA: utx.commit(); // Don't forget exception handling

    // Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling

}

The disadvantage here is that the implementation classes (i.e. ItemDAOHibernate and UserDAOHibernate) of the persistence layer are exposed to the client, the controller. Also, constructor injection of the current Session might be more appropriate.

Preparing DAOs with lookup
Alternatively, call HibernateUtil.getSessionFactory().getCurrentSession() as a fallback, if the client didn't provide a Session when the DAO was constructed:

public abstract class GenericHibernateDAO
        implements GenericDAO {

    private Class persistentClass;
    private Session session;

    public GenericHibernateDAO() {
        this.persistentClass = (Class) ((ParameterizedType) getClass()
                                .getGenericSuperclass()).getActualTypeArguments()[0];
   }

   public void setSession(Session session) {
        this.session = session;
   }

   protected void getSession() {
       if (session == null)
           session = HibernateUtil.getSessionFactory().getCurrentSession();
       return session;
   }

...

The controller now uses these stateless data access objects through direct instantiation:

// EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED)
public void execute() {

    // JTA: UserTransaction utx = jndiContext.lookup("UserTransaction");
    // JTA: utx.begin();

    // Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction();

    ItemDAO itemDAO = new ItemDAOHibernate();
    UserDAO userDAO = new UserDAOHibernate();

    Bid currentMaxBid = itemDAO.getMaxBid(itemId);
    Bid currentMinBid = itemDAO.getMinBid(itemId);

    Item item = itemDAO.findById(itemId, true);

    newBid = item.placeBid(userDAO.findById(userId, false),
                            bidAmount,
                            currentMaxBid,
                            currentMinBid);

    // JTA: utx.commit(); // Don't forget exception handling

    // Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling

}

The only disadvantage of this very simple strategy is that the implementation classes (i.e. ItemDAOHibernate and UserDAOHibernate) of the persistence layer are again exposed to the client, the controller. You can still supply a custom Session if needed (integration test, etc).

Each of these methods (factories, manual injection, lookup) for setting the current Session and creating a DAO instance has advantages and drawbacks, use whatever you feel most comfortable with.

Naturally, the cleanest way is managed components and EJB 3.0 session beans:

Writing DAOs as managed EJB 3.0 components
Turn your DAO superclass into a base class for stateless session beans (all your concrete DAOs are then stateless EJBs, they already have a business interface). This is basically a single annotation which you could even move into an XML deployment descriptor if you like. You can then use dependency injection and get the "current" persistence context provided by the container:

@Stateless
public abstract class GenericHibernateDAO
        implements GenericDAO {

    private Class persistentClass;
   
    @PersistenceContext
    private EntityManager em;

    public GenericHibernateDAO() {
       setSession( (Session)em.getDelegate() );   
    }

...

You can then cast the delegate of an EntityManager to a Hibernate Session.

This only works if you use Hibernate as a Java Persistence provider, because the delegate is the Session API. In JBoss AS you could even get a Session injected directly. If you use a different Java Persistence provider, rely on the EntityManager API instead of Session. Now wire your DAOs into the controller, which is also a managed component:

@Stateless
public class ManageAuctionController implements ManageAuction {

    @EJB ItemDAO itemDAO;
    @EJB UserDAO userDAO;

    @TransactionAttribute(TransactionAttributeType.REQUIRED) // This is even the default
    public void execute() {

        Bid currentMaxBid = itemDAO.getMaxBid(itemId);
        Bid currentMinBid = itemDAO.getMinBid(itemId);

        Item item = itemDAO.findById(itemId, true);

        newBid = item.placeBid(userDAO.findById(userId, false),
                               bidAmount,
                               currentMaxBid,
                               currentMinBid);

    }
}

P.S. Credit has to be given to Eric Burke, who first posted the basics for this pattern on his blog. Unfortunately, not even the Google cache is available anymore.

  NEW COMMENT 

Granularity  10 Sep 2005, 05:14  anthony 
Christian said:The DAO interface for a particular entity, that's ok
but can sometimes think in term of package.

Just one word about granularity, for big projects based on more than
100 persistent classes, if your design is well done, you'll have
different packages of 10-30 classes for example.

Use cases should be "driven" by a root entity for each package, so you
can define one DAO interface per package.

Example: what if you have Order * -- 1 Client and you need to get the
orders of a particular client? One use case needs only the orders, one
other also need the client to be fetched. Do you code this in
ClientDAO or OrderDAO knowing that client is the best candidate to be
a root entity...
This one is very simple but think about complex HQL queries on a 4 or
6 levels object graph. The code is not so easy to add and if you have
a big development team, there is risk to duplicate the code.

But you need to be carefull when designing your packages...
 
 
interface vs. class  23 Apr 2006, 13:17  andrewHib 
Hi,

The interface ItemDAO has to methods that retun an object of the
Bid-class. What happens if some sort of persistence mechanism needs the
class to implement an interface(Bid implements Persistable, for
example), then you can′t return the Bid class. Wouldn′t it be better
here to program against an interface Bid?
 
 
I think i found an error in the interface GenericDAO  05 Sep 2006, 14:48  juliano7s 
The implementation of the method findByExample(T exampleInstance,
String[] excludeProperty) in GenericHibernateDAO class is different from
its definition in the interface GenericDAO.

I tried to create a ItemDAO interface and ItemDAOHibernate class and got
the error
"The type ItemDAOHibernate must implement the inherited abstract method
 GenericDAO.findByExample(Item)"

Should you add the parameter to the interface GenericDAO or remove the
parameter from the GenericHibernateDAO class?
 
 
Re: I think i found an error...  29 Oct 2006, 15:02  kousen 
In case no one has answered this, check the Caveat Emptor source code. 
In there, they add the additional parameter to the findByExample
method.  As you noted, that takes care of any compilation issues.

They've also made another adjustment to the pattern as implemented by
CE.  Apparently they weren't happy with setting the persistentClass
attribute by reflection.  Instead, the latest code (HiA-SE3.1alpha5)
uses the constructor to set the class.  In the associated factory all
of the individual DAO classes call super with the class references as
an argument.
 
 
Transaction Management in DAOs  30 Oct 2006, 06:25  prashantbasawa 
Using transaction management outside the DAO is not a good idea. It
should be done inside the DAO itself. We can use a Strategy Pattern to
plug-in the transactional behaviour into the DAOs.

Declare a interface as

public interface TransactionStrategy {
   public void beginTransaction();
   public void commit();
}

Have an implementor like,

public class DefaultTransactionStrategy {
   public void beginTransaction(){
      HibernateUtil.getSessionFactory().getCurrentSession()
                                    .beginTransaction();
   }

   public void commit(){
      HibernateUtil.getSessionFactory().getCurrentSession()
                                    .commit();
   }
}

Now in the DAOs, you can have a instance variable declared for the
transaction strategy. Like

public class xyzDAO{
   private TransactionStrategy transaction = null;
  
   public xyzDAO(){
      transaction = new DefaultTransactionStrategy();
   }

   public void insert(Object obj){
      transaction.beginTransaction();
     
      // Do some work
      session.load(...);
      session.persist(...);

      transaction.commit();
   }

   public void setTransactionStrategy(TransactionStrategy strategy){
      transaction = strategy;
   }
}

Thus we can move the transaction management code to a strategy class
which will be used inside the DAOs.

In future, if you want to switch to a JTA Transaction, then you can
create a new transaction strategy for the same.

Also these strategies can be set to DAOs in
HibernateDaoFactory.instantiateDAO(Class clazz), where we have set the
session. Also, we can take the strategy info from a property file as
well. So based on a property in the property file, you can create a
strategy and set it to the DAOs.

Note: Strategy class can also accept the session through its constructor
if you define one which accepts it.
 

================以上是正文,建议看原文链接内容=====================
 
Re: Transaction Management in DAOs  30 Oct 2006, 07:28  prashantbasawa 
>Note: Strategy class can also accept the session through its constructor
>if you define one which accepts it.

Please ignore my "Note" which I wrote at the bottom of my topic.
 
 
Keep it simple  31 Oct 2006, 00:25  christian 
Of course, DAOs should not include programmatic transaction demarcation,
no matter which pattern-of-the-day you use to hide it.

At most, a DAO _can_ require a transaction context for particular methods.
This is best expressed with metadata, e.g. EJB 3.0 annotations.
 
 
Re: Transaction Management in DAOs  03 Nov 2006, 08:29  bora.erbas 
30 Oct 2006 07:28, prashantbasawa wrote:

>>Note: Strategy class can also accept the session through its constructor
>>if you define one which accepts it.

>Please ignore my "Note" which I wrote at the bottom of my topic.

so you basically mean; for every operation like persisting an object,
there should be a transaction began and committed? right?
i thought this was not a good idea...
 
 
Re: Transaction Management in DAOs  13 Nov 2006, 02:12  prashantbasawa 
POST QUESTIONS ON THE FORUM! COMMENTS HERE SHOULD ADD VALUE TO THE
PAGE!On 03 Nov 2006 08:29, bora.erbas wrote:

>so you basically mean; for every operation like persisting an object,
>there should be a transaction began and committed? right?
>i thought this was not a good idea...

How many operations are you going to have for persisting ? Only 3,
INSERT, UPDATE and DELETE which you can implement in a super class. So
there is no replication of code. Only things that vary for DAOs are the
way you query (SELECT) the respective tables, I don't thing u should use
transaction begin-commit for selecting rows of data where u r not making
changes to database.

I hope this answers ur doubt.
 
 
Re: Transaction Management in DAOs  14 Nov 2006, 05:19  christian 
>way you query (SELECT) the respective tables, I don't thing u should use
>transaction begin-commit for selecting rows of data where u r not making
>changes to database.

Nonsense. Of course you want regualar ACID guarantees for reading data,
especially if you want repeatable read isolation. Stop promoting the same
old "I don't really know what auto-commit is" story.
 
 
Salto-db Generator  27 Feb 2007, 04:59  rflament 
Just to let you know I have written a tool that generates code from the
database and one of the plugin, called "EJB3AndHibernateDao" generates
code based on this pattern.

It generates a pojo or an ejb3 for each table, a generic dao for each
pojo and an hibernate implementation of this dao.

See http://salto-db.sourceforge.net/salto-db-generator/index.html and
http://salto-db.sourceforge.net/salto-db-generator/plugins/ejb3hibernatedao.html

Thanks a lot for this article.
 
 
Re: Salto-db Generator  19 Mar 2007, 09:54  rjain15 
POST QUESTIONS ON THE FORUM! COMMENTS HERE SHOULD ADD VALUE TO THE
PAGE!On 27 Feb 2007 04:59, rflament wrote:

>Just to let you know I have written a tool that generates code from the
>database and one of the plugin, called "EJB3AndHibernateDao" generates
>code based on this pattern.

>It generates a pojo or an ejb3 for each table, a generic dao for each
>pojo and an hibernate implementation of this dao.

>See http://salto-db.sourceforge.net/salto-db-generator/index.html and
>http://salto-db.sourceforge.net/salto-db-generator/plugins/ejb3hibernatedao.html

>Thanks a lot for this article.

rflament: This is the a very useful plugin. I was looking the DAO
Generation and SalTo-DB is a good fit. Keep up the good work.

rjain
 
 
Transaction scope  14 May 2007, 05:42  Olivier Billard 
>Using transaction management outside the DAO is not a good idea. It
should be done inside the DAO itself.

Since I did not read a valid answer to this statement, here I am :).
Transaction should NOT be open/closed inside DAO themselves. This is
really a really idea :

- in that case you cannot include several DAO calls into one transaction
(atomicity on several entities CRUD cannot be done). This is more than a
little bit restrictive !
- in a JTA transaction, you may not have the control on the transaction
scope, you may just "participate" to the transaction (see first point)

I think that these only 2 points make it obvious, not to call
transaction begin/commit in the DAOs themselves. Of course, more can be
added.