|
锁定老帖子 主题：关于DAO层的疑惑!!!平地一声雷
精华帖 (0) :: 良好帖 (1) :: 新手帖 (14) :: 隐藏帖 (6)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-08-08
hanzhicheng754 写道 事实上，在设计DAO层时，还有一个问题，是我们经常忽略的问题，那就是并发。如果你的设计中，确实考虑这个问题的话，将会发现这是一件非常棘手的事情。在软件这个行业，我觉得，真正的真理是，没有银弹，通用的设计，往往是以牺牲灵活性为代价的，而且随着业务复杂性的增加，你会发现，你愈加的力不从心。具体问题，具体分析，不是为了设计而设计，不是为了美学而设计，实事求是。
|
| 返回顶楼 | |
|
发表时间：2011-08-09
白糖_ 写道
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的，对项目的转型和升级影响小很多。 如果项目做成产品，持久层该用什么框架完全要看实际情况，那时就可以轻松实现框架的切换。
以上是我的拙见，不知可行否。
我觉得这样挺好的，东西是多了点，但不乱。 |
| 返回顶楼 | |
