|
锁定老帖子 主题：只需要一个DAO，是个好主意吗？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (5) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-11-26
我看上面的楼主所说的DAO怎么那么像我老师说的一样呢?????用DAO能让MVC模式更加实用快捷.
|
| 返回顶楼 | |
|
发表时间：2008-11-27
你同仁说的对，在dao层封装一下，会省很多事情。
|
| 返回顶楼 | |
|
发表时间：2008-11-28
是不是应该用一个公共dao,再根据需要继承这个dao,进行扩展
|
| 返回顶楼 | |
|
发表时间：2008-11-28
timerri 写道 如果真能只用一个dao解决，那么祝贺你，你得到了一个虚拟数据层(高度抽象的数据接口)。这是一个比dao更高级的存在...
这个……为什么大家都用javabean,property + getter+setter, 本身泛型多态，完全可以一个Row model代替的，db = rowset(封装一批方法，排序、权限) = row(封装一批方法，验证数据、权限等) 这样表现层也简单了，dao，就几个方法create/update/insert/getone/list/listbyfield/listinpage/(search)等，这个不是很好吗？ 最近我写了一个，用着还行，自绎得几乎除了sql语句中的ddl需要手写，其他的全部是自动的。 欢迎来交流 |
| 返回顶楼 | |
|
发表时间：2008-11-29
LZ 是在因为DAO层过于简单 所以才质疑需不需DAO吧。
哪么这个SB的问题 就不要去想了 该怎么用就怎么用。 用了框架没什么难度的东西，我不相信能影响到你后期的维护。 |
| 返回顶楼 | |
|
发表时间：2008-12-09
最好的DAO还是作为一个服务发布吧。在大型项目中这个应该有点用
|
| 返回顶楼 | |
|
发表时间：2008-12-09
过度的抽象,
带来的是理解困难. 总的说来, 一个DAO不能产生足够的信息 用来指示代码作用 对维护会产生更大的困难 一个DAO所要写的测试代码太多 如果不能写全, 隐含的逻辑错误很难捕捉 建议将查询还是单写DAO. 增删改,继承得来 |
| 返回顶楼 | |
|
发表时间：2008-12-09
wolfwolfgod 写道 目前的J2EE架构中，大多都有DAO层，在我们的项目实践中也是这样，而且由于使用了Hibernate或者Ibatis这样的持久层框架，把SQL都放在了外部的XML文件中，由一个ID来引用。
现在的问题是，大多数的情况下，在DAO中我们只是简单传参数，然后运行指定ID的SQL/HQL,所以有同仁提出，建立一个单一的DAO类，封装了基本的操作，然后在Service层都引用这个DAO，直接传SQL-ID和查询参数，就不用写那么多DAO类了，可我觉得这样就不是一个DAO层了，退化为一个类似工具类的东西，所以放在这里大家讨论一下，此方式有何优缺点或不妥的地方。 那service层 就做了DAO的事情了，会把service层搞得很复杂，DAO变成了一个工具类了 |
| 返回顶楼 | |
|
发表时间：2008-12-09
jeff.chuh 写道 使用1个共通的DAO当然最好，因为这样会为你省去非常多的类，而那些类里的逻辑往往差不多。当然是用共通的DAO你需要对结果转型，转成你需要的bean，但这也比写那么多DAO强多了，或者你可以让结果的类型变为Map，那样更适合共通化。你可以放下包袱，只关注你的业务逻辑。
结果放Map里是否会影响性能呢 |
| 返回顶楼 | |
|
发表时间：2008-12-09
eluyouni 写道 分层是有针对的，小项目不用开源框架，用 jsp加servlet即可；
中型项目用SSH时可以用一个公共的DAO； 对于大型的项目就有必要service(biz) 对应一个dao,在处理时会有很多数据操作不同的地方， 这样更容易维护！ 这个好像不分项目大小的吧 
|
| 返回顶楼 | |
