|
锁定老帖子 主题：一次关于简化DAO设计的初步思考！
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-10-10
potian 写道 DAO本身的目的有两个：
1。提供统一的存取层，以便外部框架和机制针对这一层进行特别的处理，或者外部可以提供这一层次上的超类为你服务，你可以在一个明确的层次上重用别人的工作，但这不是专门针对DAO，而是分层结构自动带来的好处。 2。而DAO本身的目的就是为了封装数据存取的差异性，如果你直接用这种方法来做的话，DAO有什么用，根本不需要了
List users=(List);getDao.find("findUserWithFullName",parameters);;
如果DAO改成 JDBC实现，这算什么？ 呵呵，确实如此。颠覆了DAO的根本原则。我错了，大错特错。 |
| 返回顶楼 | |
|
发表时间：2004-10-10
potian 写道 2。而DAO本身的目的就是为了封装数据存取的差异性，如果你直接用这种方法来做的话，DAO有什么用，根本不需要了
List users=(List);getDao.find("findUserWithFullName",parameters);;
如果DAO改成 JDBC实现，这算什么？ 用JDBC当然也可以用这样一个parameters的map来传递, 而且偶在实际项目中就是这样做的.
public class JDBCDao implements IDAO{
public List find(String namedQuery, Map parameters);{
getConnection();;
getObjectFromMap(parameters);;
createStatment(namedQuery);;
setupParameters(pramaeters);;
return result;
}
}
把findUserWithFullName这个对应的query写在配置文件里面, 其实有点像iBatis的做法了 |
| 返回顶楼 | |
|
发表时间：2004-10-10
因为我的queryObject的设计依赖于hibernate的Session
find("findUsersByFullName",set ps) 而我传进来的name参数是为了寻找queryObject。 如果换成JDBC的实现的话，至少我这里的设计就失去了意义，至少需要重新修改queryObject以让他充当封装DAO具体实现的代理。从整体意义来说，我思考是逻辑错误的。 |
| 返回顶楼 | |
|
发表时间：2004-10-10
firebody 写道 因为我的queryObject的设计依赖于hibernate的Session
find("findUsersByFullName",set ps) 而我传进来的name参数是为了寻找queryObject。 如果换成JDBC的实现的话，至少我这里的设计就失去了意义，至少需要重新修改queryObject以让他充当封装DAO具体实现的代理。从整体意义来说，我思考是逻辑错误的。 没有注意到你的QueryObject里面竟然有一个session....., 杀...... 
|
| 返回顶楼 | |
|
发表时间：2004-10-10
Readonly 写道 firebody 写道 因为我的queryObject的设计依赖于hibernate的Session
find("findUsersByFullName",set ps) 而我传进来的name参数是为了寻找queryObject。 如果换成JDBC的实现的话，至少我这里的设计就失去了意义，至少需要重新修改queryObject以让他充当封装DAO具体实现的代理。从整体意义来说，我思考是逻辑错误的。 没有注意到你的QueryObject里面竟然有一个session....., 杀......  
本来想让它方便产生Criteria ,Query对象的。
|
| 返回顶楼 | |
|
发表时间：2004-10-10
不现实
NamedQuery findUserWithFullName是hibernate特有的，外部Service调用的方式就是
List users=(List);getDao.find("findUserWithFullName",parameters);;
你要变成 JDBC的DAO，不能影响这一点 createStatment(namedQuery);; 你怎么从findUserWithFullName去创建出你的SQL语句，除非内部实现一套类似于Hibernate的NamedQuery机制 还有最重要的是DAO方法名字的意义和明确的参数，到时候大家都不知道要放什么参数了，放几个参数了，而到底一个DAO提供哪些功能，也不知道，因为接口只有一个方法，而到底返回什么东东，是一个列表还是一个对象，对象是什么类型，也不知道，这样的代码怎么维护和扩展 |
| 返回顶楼 | |
|
发表时间：2004-10-10
potian 写道 不现实
NamedQuery findUserWithFullName是hibernate特有的，外部Service调用的方式就是
List users=(List);getDao.find("findUserWithFullName",parameters);;
你要变成 JDBC的DAO，不能影响这一点 createStatment(namedQuery);; 你怎么从findUserWithFullName去创建出你的SQL语句，除非内部实现一套类似于Hibernate的NamedQuery机制 还有最重要的是DAO方法名字的意义和明确的参数，到时候大家都不知道要放什么参数了，放几个参数了 如果硬是要讲错就错的话，我会重新设计QueryObject以封装Hibernate或者JDBC实现。不过这样的设计就显得无味了而且无聊拉。至于Name，基本的概念就是一个查找查询对象的作用，至于明确参数的意义，还是可以通过一套验证机制来检查参数的合法性，包括name的检查。 不过确实失去了OO的本意。 |
| 返回顶楼 | |
|
发表时间：2004-10-10
偶前面说过了用配置文件, 而且偶的配置文件很简单:
NamedSQL.properties findUserWithFullName=select user_id, full_name from user where full_name = $fullName createStatment(namedQuery)要做的工作就是从这个配置文件里面找出这句话, 然后把占位符号替换成? |
| 返回顶楼 | |
|
发表时间：2004-10-10
我认为在这里，显示的DAO接口就是一份可以验证的，明确说明的数据存取文档，这样的文档我们还是有必要维护的，何况还有移植性的好处
|
| 返回顶楼 | |
|
发表时间：2004-10-10
Readonly 写道 偶前面说过了用配置文件, 而且偶的配置文件很简单:
NamedSQL.properties findUserWithFullName=select user_id, full_name from user where full_name = $fullName createStatment(namedQuery)要做的工作就是从这个配置文件里面找出这句话, 然后把占位符号替换成? 同意，复杂的查询我会选择你的方式。也可以提供一个比较统一的实现。 |
| 返回顶楼 | |
