Graduated B.s.c Information System Engineering on BGU Uneversity (2004). Co-founded few startups in the domain of socail web. Been working on large cloud based ERP application in SAP for 7 years. Currently working as a development group manager in affiliation company. Gal is a DZone MVB and is not an employee of DZone and has posted 6 posts at DZone. You can read more from them at their website. View Full User Profile

DAO Layer - Generics to the Rescue

09.28.2012
| 15652 views |
  • submit to reddit
Generics can be a powerful tool to create reusable code with the power of compile time verification (type safety..).
Unfortunately I feel the main stream developers still afraid of it.
However, in analogy to Hagrid's spiders I would say that Generics are seriously misunderstood creatures... :-)

I hope the following example will demonstrate how useful they can be.

The Problem - DAO (Data Access Objects) classes have common methods such as save, update, delete, loadAll.. which are required in every DAO class.
Writing a base class with these common methods and making every DAO object extend it, is simply not enough since each DAO class represents a different domain class and therefore the type used in the common methods' signature is different (although implementation is similar), for example:
class OrderDAO {
//save method receive an Order
public void save(Order order){....}
//getAll method return Orders List
public List<Order> getAll(){...}
}
 
class UserDAO{
//save method receive an User
public void save(User user){....}
//getAll method return Users List
public List<User> getAll(){...}
}

How Generics can help us create a base class with a common implementation and yet, keep method signature type-safety?First, we need to define an interface with the common methods:
/**
 * Base interface for CRUD operations and common queries
 */
public interface IDaoBase<T> {
     
    public List<T> loadAll();
     
    public void save(T domain);
         
    public void update(T domain);
         
    public void delete(T domain);
     
    public T get(Serializable id);
     
    /**
     * Get list by criteria
     * @param detachedCriteria the domain query criteria, include condition and the orders.
     * @return
     *
     */
    public List<T> getListByCriteria(DetachedCriteria detachedCriteria);
     
    public List<T> getListByCriteria(DetachedCriteria detachedCriteria, int offset, int size);   
}

Please note that we utilize generics so each method signature has a type T, which in the implemented DAO classes, will be a concrete type, per domain.

The second step is to create an abstract class which implements the common functionality:
public abstract class DaoBase<T> extends HibernateDaoSupport implements IDaoBase<T> {
    private Class<T> entityClass;
     
    @Autowired
    public void setSession(SessionFactory sessionFactory){
        this.setSessionFactory(sessionFactory);
    }
         
    public DaoBase() {
         
        entityClass = (Class<T>) ((ParameterizedType) getClass()
                .getGenericSuperclass()).getActualTypeArguments()[0];
    }
 
        public List<T> loadAll(){
        return getHibernateTemplate().loadAll(entityClass);
    }
 
    public void delete(T domain) {
        getHibernateTemplate().delete(domain);
    }
 
    public void save(T domain) {
        getHibernateTemplate().saveOrUpdate(domain);
         
    }
 
    public void update(T domain) {
        getHibernateTemplate().merge(domain);
    }
     
     
        public T get(Serializable id) {
        T o = (T) getHibernateTemplate().get(entityClass, id);
        return o;
    }
 
    public List<T> getListByCriteria(DetachedCriteria detachedCriteria,
            int offset, int size) {
        return getHibernateTemplate().findByCriteria(detachedCriteria, offset, size);
    }
     
    public List<T> getListByCriteria(DetachedCriteria detachedCriteria) {
        return getHibernateTemplate().findByCriteria(detachedCriteria);
    }
}
 
And that's it !
Take a minute or two to inspect how the base object implements a generic functionality with a type-safety manner.

All we have to do when implementing a new DAO is:
1. Interface to extend the IDaoBase with a concrete type
public interface DaoUser extends IDaoBase<User> {//<=Notice the User typing
    //Add any additional custom methods..
    public User getbyUsername(String username);
        public User getbyEmail(String email);
}

2. Implementation to extend the DaoBase with a concrete type
//This class has all the common methods, which are type safe for the User class
@Repository("daoUser")
public class DaoUserImpl extends DaoBase<User> implements DaoUser { //<=Notice the User typing
 
    public User getbyUsername(String username) {
// concrete implmentation       ...
    }
So now you see how powerful it is to use generics. Hope it is now a bit less scary and more understood...

Please post me if you have further cool tricks utilizing generics for ease development.

Moreover, if you think any of the above can be improved, I'll be happy to hear about it. 
 
Published at DZone with permission of Gal Levinsky, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Marek Dec replied on Sat, 2012/09/29 - 5:48am

Oh God, there are so many wrong things about this article it shouldn't really appear here. Starting with the naming pattern, IBaseDao are simply wrong BaseDaoImpl, and they not wrong because of the fact they are ugly, but that they lead to serious problems in the API .

If they were named CRUDDao and CRUDHibernateDao, the author would probably notice that the Hibernate API is leaking through the interface. I could bet a lot of money, there will be no other implementations or IBaseDao than Hibernate implementation ever (except for mock one, of course, but  man it's 2012 and things like EasyMock or Mockito are out there for a couple of years already). And that is because the IBaseDao#getListByCriteria method requires a parameter of DetachedCriteria class that belongs to the HibernateAPI.


Another great flaw of this design is that it will result in n DAOs for n DB mapped objects (which may sound reasonable at first). Though if you think of it in terms of Java Classes/Objects and assuming that your application does only CRUD operations (this assumption is not necesary, just to make it easier to understand) you will get n identical classes with a just one difference: the generic type. Is this the Java way? Nope - if you were taken outside of JEE context you'd have only one such a class and you'll objects will define the generic parameter (i.e. there will be no StringList implements List<String>). And as the JEE mindset has been twisted so much into using procedural (and not Object Oriented) programming, we end up having such solutions all over the place. Your Spring or whatever DI container does not force you to make all classes singletons.
Why would I need CRUDUserDao class, while I could have a CRUDDao<User> object of a CrudDao<T> class (the type of the DB mapped class could be passed by ctor argument to my DAO by Spring for example). And if I'd need any more specilaized DAO, I'd create it is when it's needed and I'll call it something different.

Last of all, I wouldn't be surprised to see this kind of article some 5 years ago, but nowadays this exact piece of (wrong) generic design is all over the place and it's probably time to write article that point this out.

Gal Levinsky replied on Sun, 2012/09/30 - 2:06am in response to: Marek Dec

Hi Marek,

This article is for developers who wish to undertand the "magic" behind frameworks such as Spring Data JPa.

Even if naming is not 100% correct, I hope it is clear enough since the idea here is to convey the principle in simplified manner and provide demonstration of how to utilize generics.

Marek Dec replied on Sun, 2012/09/30 - 3:59am in response to: Gal Levinsky

Gal,

 I agree your examples contain a lot of didactic value, though this article should appear in a somehow different context.


From the technical point of view, my major complaint is not about the naming pattern - this is the least important even though it leads to the consecutive flaws. And it's not about about the fact the underlying technology (namely hibernate) leaks to the 'implementation agnostic' interface. And note that is  a severe flaw in the design, that makes the whole 'Interface <-> Implementation' overhead just completely useless.

The problem here is that the magic you are showing here is abusing the common sense behind Java generics. Let me use an analogy here. What you are trying to say is that to deal wih a list of Strings, a developer should create a class called StringList that extends List<String> and in order to play with a list of Longs, a similar class called LongList should be created. And I've seen this pattern a lot of times, I know it works just fine and I even used it myself once. This doesn't change the fact, however, that it is an antipattern. And I guess that JEE community grew smart enough over the years to notice that. This is the context I was spoke about in the beginning.

 

Jeff Devis replied on Mon, 2012/10/01 - 12:41pm

Marek

As newbie I didn't understand where is the problem, can you please give us a link where the antipattern is explained

thanks

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.