|
锁定老帖子 主题：关于DAO层的疑惑!!!平地一声雷
精华帖 (0) :: 良好帖 (1) :: 新手帖 (14) :: 隐藏帖 (6)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-08-03
http://book.douban.com/subject/1629512/
解决你的问题 |
| 返回顶楼 | |
|
发表时间：2011-08-03
小鑫。 写道 通用Dao里只是装着各个通用的方法,每个Model还应该有个属于自己的Dao,用来存储自己特有的方法. +1 |
| 返回顶楼 | |
|
发表时间：2011-08-03
仅此而已 写道 楼主是否精通flex呢？ 小弟想学，就是找不到师傅，各种问题各种有！ 呵呵
我不会flex,不过我们部门有用,有人会,我可以给你推荐一下 |
| 返回顶楼 | |
|
发表时间：2011-08-03
最后修改：2011-08-03
DAO:
public interface StudentDao extends BaseDAO<Student>{ } DAOImpl: public class StudentDaoImpl extends BaseDAOImpl<Student> implements StudentDao{ } Service: public interface StudentService extends BaseService<Student, StudentDao>{ } ServiceImpl: public class StudentServiceImpl extends BaseServiceImpl<Student, StudentDao>implements StudentService{ } 大概就是这个样子，我们一直这样使用 在BaseDAO<Type>里定义了常用的CRUD方法，BaseDAOImpl<Type>实现BaseDAO这个接口中的所有方法，这样子就最大程度的达到代码复用，像上面的StudentDao，如果没有什么特殊的DAO操作，这个接口里面完全可以不用去定义什么方法了。 |
| 返回顶楼 | |
|
发表时间：2011-08-03
edisonlv2010 写道 DAO:
public interface StudentDao extends BaseDAO<Student>{ } DAOImpl: public class StudentDaoImpl extends BaseDAOImpl<Student> implements StudentDao{ } Service: public interface StudentService extends BaseService<Student, StudentDao>{ } ServiceImpl: public class StudentServiceImpl extends BaseServiceImpl<Student, StudentDao>implements StudentService{ } 大概就是这个样子，我们一直这样使用 能不能说的详细点,或者把你的dao层,service层和xml文件发一份过来呢?谢谢了~ |
| 返回顶楼 | |
|
发表时间：2011-08-03
最后修改：2011-08-03
我现在的做法是 写一个泛型dao ，所有的modelDAO 都继承他 ，没有特殊的操作modelDAO 里面是没有代码的。 要有特殊的可以自己在modelDAO里面写。我觉得如果单纯的用通用dao 也会有问题，比如我突然想加以个方法了。但是不应该写到通用dao里面去。还是得新建一个，这样有的service直接使用通用dao 有的是用自己写的dao，这样我觉得不规范 ，本来没有的新加一个还得去该配置。所以我干脆全部都写一个modelDAO可能很多里面是没有代码的，但是为了规范。加方法也方便
至于配置麻烦 我推荐用注解 |
| 返回顶楼 | |
|
发表时间：2011-08-03
你一个人在干活吧？如果在大公司，参考一下内部框架你会有很大的收获。
我目前的方法是定义一个commonDao，每个service里都有commonDao,当然如果你觉得这个也冗余那么可以定义个baseService,跟楼上有人说的baseDao的思想一样，基本的create,delete,update,getById,findByPage()，都有。 不过我们应该优先使用组合而非继承，使用组合的话耦合性很低，方便重用。继承产生依赖，应该慎用。 |
| 返回顶楼 | |
|
发表时间：2011-08-03
energykey 写道 你一个人在干活吧？如果在大公司，参考一下内部框架你会有很大的收获。
我目前的方法是定义一个commonDao，每个service里都有commonDao,当然如果你觉得这个也冗余那么可以定义个baseService,跟楼上有人说的baseDao的思想一样，基本的create,delete,update,getById,findByPage()，都有。 不过我们应该优先使用组合而非继承，使用组合的话耦合性很低，方便重用。继承产生依赖，应该慎用。 commonDao满足不了的功能，比如很复杂的查询，通过单独的Dao吗？ |
| 返回顶楼 | |
|
发表时间：2011-08-03
白糖_ 写道
feiyang404 写道
我个人认为,dao层只应提供数据持久化接口,和数据库,Service层均没有关系,如果持久化框架变了,比如不用Hibernate,而改用ibatIS,那么只需要将DAO里面的实现稍作改动,整个系统就可以流畅运行.所以,这就要求在Service层不要写HQL或者QBC,Service层专注调用DAO层接口为Action层提供服务,和DAO层无耦合.这样如果写一个通用DAO层的话,就会提高代码重用性,并且xml配置也很简洁,只要配置一个通用的dao就可以了,但是却使以牺牲灵活性为前提的,比如在Service层需要一个按属性查询的方法,那么在DAO层就要写where子句(where xxx=yyy),但是通用dao不可能知道xxx,怎么办呢?
如果通用DAO层接受Service层传来的HQL的话,那就会很容易写出一个灵活性高,重用性强的DAO通用层,但是这样又有了耦合性,持久化框架变化的话要改变的代码会很多,甚至可以说是牵一发而动全身.
这位朋友跟我的想法完全合到一块了，最初我就是用service直接调用BaseDao的方法，Hql都写到service中。 但是当我认真审视整个项目结构的时候，我发现问题很大：如果将Hibernate换成MyBatis，不止是整个Dao层要修改，Service层也要做大量改动，而且改动之后单元测试也要重新做。 目前我的考虑可能跟LZ一样：老老实实针对一个model写一个Dao，对service只提供接口，具体实现可以根据使用什么框架定制开发，这样做的好处是： 我可以写多套Dao接口的实现类：Hibernate的、Mybatis的、甚至JDBC的，对项目的转型和升级影响小很多。 如果项目做成产品，持久层该用什么框架完全要看实际情况，那时就可以轻松实现框架的切换。
以上是我的拙见，不知可行否。 同意上面的观点。
个人觉得Service层应该负责业务逻辑，需要持久化的时候，调用对应的DAO接口，至于DAO的实现则可根据不同ORM框架而不同。 初步考虑觉得可以一个总的DAOSupport类，负责具体不同ORM框架的初始化，配置等问题，并通过某种方式(例如，通过一个简单的枚举变量来标记)选用具体的ORM实现。其中sql语句的组装抽象到配置文件(这点Ibatis已经做的不错了)。每个DAOImpl实现都继承这个DAOSupport类。这样在使用的时候，只要通过具体的DAO类通过注解注入即可。 |
| 返回顶楼 | |
|
发表时间：2011-08-03
习惯大于配置， 你dao是可以抽象的， 再者建议你用annotation， 少用配置。
|
| 返回顶楼 | |
