|
锁定老帖子 主题：只需要一个DAO，是个好主意吗？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (5) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-11-07
你说的一个指的是一个比较底层的DAO,这个DAO是与业务没有关系的
但实际项目当中,需要一个DAO来封装具体的业务操作使用的BizDAO,这个DAO才是在service里面调用的那个DAO |
| 返回顶楼 | |
|
发表时间：2008-11-07
在项目开发中主要是要体现一个分层的思想
|
| 返回顶楼 | |
|
发表时间：2008-11-07
我建议废弃dao,直接把sessionFactory注入Service层 如何?
|
| 返回顶楼 | |
|
发表时间：2008-11-07
我现在就是用一个dao，sql写在service层里当作参数传递给dao
我对此的解释是service是业务逻辑层，sql也是根据业务决定的，所以sql放在service层是理所当然的 到目前为止这种模式用的很爽 |
| 返回顶楼 | |
|
发表时间：2008-11-07
分层的目的是啥？为了多人协作,结构清晰,维护方便...
假如你一个人维护多层, dao 怎么写多无所谓了... |
| 返回顶楼 | |
|
发表时间：2008-11-07
个人觉得还是用一个BaseDAO把一般的操作封装在里面，实际应用的各个DAO扩展这个BaseDAO加入一些特殊的方法由不同的service层来调用比较好些。要不然一个DAO考虑的东西太多了，而且很臃肿，不是吗？？
|
| 返回顶楼 | |
|
发表时间：2008-11-07
最后修改：2008-11-07
ywlqi 写道 我现在就是用一个dao，sql写在service层里当作参数传递给dao
我对此的解释是service是业务逻辑层，sql也是根据业务决定的，所以sql放在service层是理所当然的 到目前为止这种模式用的很爽 你不能把业务层和数据存取层混在一起吧，这样代码没有得到最大限度的复用，开发效率太低了。。。 |
| 返回顶楼 | |
|
发表时间：2008-11-07
最后修改：2008-11-07
魔力猫咪 写道 CRUD中最麻烦的是查询。每个对象都有一大堆查询方法，千奇百怪五花八门。所以现在的Dao膨胀得很厉害。加上很多人不能理清楚Service和Dao的关系，Action里都是HQL。
所以如何在隔绝具体实现的情况下零花灵活查询才是问题所在。希望JPA2能够给出一些更好的解决办法。虽然Hibernate和Jpa中也可以使用命名查询。但是很多时候查询参数是不定的。比如查一个对象的创建时间在某个起始时间到某个结束时间之间。这是一个很常见的情况。但是这其实是三个查询，一个是只有开始时间、一个只有结束时间还有就是两个都有。命名查询就需要3个。推论到所有的对象上，命名查询会疯长的。 你不会用规约吗，还是多学学设计吧，不要为了用框架而用框架 |
| 返回顶楼 | |
|
发表时间：2008-11-07
那要看你的DAO能做什么了,
如果你的DAO如同一个数据中间平台,我看也可以. |
| 返回顶楼 | |
|
发表时间：2008-11-07
最后修改：2008-11-07
这个帖子这么热吗，
我做过日本东芝的一个框架项目， 项目中就使用的是一个共通的DAO。 这个DAO封装了一些查询，更新，插入，删除等的方法， 而这些方法足够你用来对DB进行各种操作， 对于不用的查询，你只需要传递不同的SQLID作为参数。 这样Service由DAO得到需要的数据，进行业务处理，然后在由DAO保存或更新数据。 开发者只需要把关注点放到Service的业务逻辑和iBatis的SQL上， 减少了很多没有必要的DAO类和重复的DAO代码。 现在已经用这个框架开发好多项目了。 但是话说回来，DAO并不一定只与RDB打交道， 比如有一天你的客户让你把现在运行在RDB上的系统改造成运行在LDAP或者是其他数据源， 那么你需要实现共通DAO的接口，实现一个对应于新数据源的DAO， 但你需要对自己打个问号，可以用iBatis实现与RDB打交道的共通DAO， 但是其他的数据源你是否也能这么简单的实现共通的DAO。 |
| 返回顶楼 | |
