基于hibernate的通用、”万能“Dao的设计（一）

    基于springside3的Dao层设计思路，我按照个人想法改进了设计。基本的BaseDao，提供很多通用的操作方法，可以方便地扩展；设计一个泛型GenericDao，设计一个理想的万能UniversalDao(不能用于多数据源)；
    springside3.1.2通过在service中注入sessionFactory的方式，间接new出来任何daomain的Dao，这样的方式我觉得不是很好，但是我仍然保留了泛型dao的这个能力。代码片段如下：
   

public GenericDao(SessionFactory sessionFactory, Class<T> entityClass) {
		super(sessionFactory);
		this.entityClass = entityClass;
    }

    上述方式提供的灵活性，但是我认为造成了分层混淆，既然service有了直接获取sessionFactory的能力，还需要Dao层干什么，直接把service和dao合并成一层，只保留service层就可以了(这样的做法很多人在实际项目中就是这么干的，简单直接有效，有的童鞋认为这种方式是最佳实践)。
    为什么要搞个万能UniversalDao？想偷懒撒。
    现有简单的对象User,Role,Group,都搞一遍UserDao,RoleDao,GroupDao，由于功能简单，都是空的，这样的dao就用一个UniversalDao搞定得了，调用方法的时候把class穿进去就可以了，干脆！
   

如get方法 public Object get(Class<?> clazz, Serializable id) {
		return this.getSession().get(clazz,id);
	}

    对于规模小的系统，复杂的方法都搞到service中，Dao层我认为OnlyOneDao一个就够了。   
    代码写出来了，用起来也不错，但是万能UniversalDao的优点、缺点也是很明显的，而且里面的方法相当于重复了BaseDao，使用的时候可能造成困惑，无奈的折中。当然，如果直接使用“涨血模型”，把Service、Dao能力都合并进domain最是彻底，但是Java里面实现起来还是太复杂、难看。

改为继承HibernateDaoSupport 就完美了

------------父类
protected Class<?> entityClass;
-------------子类
public Object get(Class<?> clazz, Serializable id) {  
        this.entityClass = clazz;  
        return get(id);  
    }  

LZ有没有想过多用户环境下线程安全问题呢？

确实还没有仔细想过线程安全的问题，但是这里需要线程安全么，请详细说说。