基于hibernate的通用、”万能“Dao的设计(一)
程序员文章站
2022-07-14 21:23:12
...
基于springside3的Dao层设计思路,我按照个人想法改进了设计。基本的BaseDao,提供很多通用的操作方法,可以方便地扩展;设计一个泛型GenericDao,设计一个理想的万能UniversalDao(不能用于多数据源);
springside3.1.2通过在service中注入sessionFactory的方式,间接new出来任何daomain的Dao,这样的方式我觉得不是很好,但是我仍然保留了泛型dao的这个能力。代码片段如下:
上述方式提供的灵活性,但是我认为造成了分层混淆,既然service有了直接获取sessionFactory的能力,还需要Dao层干什么,直接把service和dao合并成一层,只保留service层就可以了(这样的做法很多人在实际项目中就是这么干的,简单直接有效,有的童鞋认为这种方式是最佳实践)。
为什么要搞个万能UniversalDao?想偷懒撒。
现有简单的对象User,Role,Group,都搞一遍UserDao,RoleDao,GroupDao,由于功能简单,都是空的,这样的dao就用一个UniversalDao搞定得了,调用方法的时候把class穿进去就可以了,干脆!
对于规模小的系统,复杂的方法都搞到service中,Dao层我认为OnlyOneDao一个就够了。
代码写出来了,用起来也不错,但是万能UniversalDao的优点、缺点也是很明显的,而且里面的方法相当于重复了BaseDao,使用的时候可能造成困惑,无奈的折中。当然,如果直接使用“涨血模型”,把Service、Dao能力都合并进domain最是彻底,但是Java里面实现起来还是太复杂、难看。
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里面实现起来还是太复杂、难看。
推荐阅读
-
一个基于phpQuery的php通用采集类分享_php实例
-
自己写的一个php基于phpQuery的通用采集类
-
一个基于phpQuery的php通用采集类分享_PHP教程
-
一个基于phpQuery的php通用采集类分享_php实例
-
C#编写了一个基于Lucene.Net的搜索引擎查询通用工具类:SearchEngineUtil
-
一个基于ROW_NUMBER()的通用分页存储过程代码
-
一个基于ROW_NUMBER()的通用分页存储过程代码
-
一个基于phpQuery的php通用采集类分享
-
spring基于通用Dao的多数据源配置详解
-
C#编写了一个基于Lucene.Net的搜索引擎查询通用工具类:SearchEngineUtil