|
锁定老帖子 主题：DAO的一个讨论问题
精华帖 (1) :: 良好帖 (0) :: 新手帖 (8) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-07-17
action跟DAO中间少了一层业务逻辑层阿,按照我们自己的话叫BusinessUnit
最近正在设计一个小型通用的权限模型 过几天整理好了po上来大家看看 |
| 返回顶楼 | |
|
发表时间：2008-07-17
能适合项目就好了，任何模式，都只是大家对事物的理解方式不同而已。
|
| 返回顶楼 | |
|
发表时间：2008-07-18
一直用一个basedao 不过用的是hibernate，一个通用的dao里面包括了一些基本的查询，添加修改删除等等，各个模块dao继承这个basedao，有这个模块相对个性的查询就写到这里面，通用的查询等等就调用basedao里面的方法
|
| 返回顶楼 | |
|
发表时间：2008-07-18
你可以找找hibernate的泛型dao或者不用泛型dao也可以
|
| 返回顶楼 | |
|
发表时间：2008-07-18
范型DAO坛子上不少人都给出源代码过，搜一下吧
但是不知道在持久操作量比较高的情况下，大量利用范型DAO的反射功能会不会存在性能问题。而一般DAO那样的EntityDAO的方法利用多态的运行时动态决定类型貌似要更好一点 |
| 返回顶楼 | |
|
发表时间：2008-07-18
现在还有人把和数据库的操作写在页面上啊？？？？
|
| 返回顶楼 | |
|
发表时间：2008-07-18
sunsong 写道 rihoonet 写道 DAO模式，我觉得太难用了，表结构一改，好多的地方都要改。
那应该是你没有理解DAO模式的好处，如果你分层分得好，即使表结构修改，你要修改的类也是限定于某一个或者几个层里面，另外一些层次，不受影响。 搂主的想法是对的，其实就是应该在设置一个业务逻辑层 比如Jsp->Action->Bussiness->Dao->PO 同意，其实我在面试的时候也问过很多程序员，他们大多数没有把DAO模式的真正作用和思想讲出来，只是说DAO是个数据访问对象，其实可以查阅一下java.sun.com的Blueprint的J2EE Design Pattern Catalog，里面对DAO有精确严谨的描述，DAO出现就是为了向上层屏蔽底层的访问逻辑，设计上来讲，上层关心的只是增删改查，并不关心你底层是用什么持久化策略（内存、数据库、文件、JMS，如果是数据，是MySQL还是Oracle还是其他，还是使用Hibernate，iBatis等ORM），只有做到这样，底层持久化实现的变化才不会影响上层，所以，把SQL语句暴露到DAO的方法签名上，事实上DAO已经变成傀儡了，同样，如果底层用了Hibernate，把与HIbernate有关的东西，如HQL，Query接口等暴露到你的DAO方法签名上，DAO也成为傀儡。 |
| 返回顶楼 | |
|
发表时间：2008-07-18
laiseeme 写道 一直用一个basedao 不过用的是hibernate，一个通用的dao里面包括了一些基本的查询，添加修改删除等等，各个模块dao继承这个basedao，有这个模块相对个性的查询就写到这里面，通用的查询等等就调用basedao里面的方法
这种做法很好，我一向也是这样用，同时把BaseDAO设计成支持泛型，就更加通用和严谨。当然BaseDAO要是接口，把实现屏蔽起来。 |
| 返回顶楼 | |
|
发表时间：2008-07-18
rihoonet 写道 那不是DAO模式的好处，是你分层分得好。。 有点可笑 DAO 不是分层分得好 那怎么会这么流行呢？ |
| 返回顶楼 | |
|
发表时间：2008-07-18
上个星期之前我就在action里面直接使用DAO层，没分业务逻辑层（刚刚开始工作，经验少），结果经理要改需求，我是拆了东墙补西墙，结果搞的提心吊胆，每天都担心是不是哪块又要出现问题了，那种感觉真郁闷..
建议action和DAO的中间加上业务逻辑层，我想会好过很多，至少改的时候麻烦很少，其他的地方不动，改些简单的地方就行了 个人的感觉，下面继续拍砖吧 |
| 返回顶楼 | |
