浏览 6100 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-06-26
遇到同样问题的同学可以来参考 今天的问题是这样地 使用IBATIS来做持久层框架,我们可以很轻松的写出动态SQL语句(一条SQL干很多事情) 一个语句可以通过不同的条件来得到不同过滤粒度的结果。 DAO中也是接收一个VO为参数,里面有SQL所需要的所有条件。通过改变VO中属性的组合,得到不同的结果。 在Facade层中可以有几种命名的选择 比如得到系统用户这样的方法 1.List getUsers(Object obj){} 我们简称大对象的方式 这个obj里面可以有很多属性比如userId,userName,roleId等等.通过调用端传来的值不同得到结果也不一样 比如 userId = -1 userName = "tom" roleId = "employee" dept="" 这样的条件就会查出 所有叫tom的员工. 如果dept有值就会查出dept所有叫tom的在某部门的员工 遇到的问题是这样的:如果着个程序或者SQL是自己写的还好办些,如果是别人写的而且SQL中的判断相当复杂(产生不同结果).那维护和调用这个方法的人就郁闷死了。因为要一直看到SQL文才会知道传什么样的参数才能得到自己想要的结果.如果SQL文中判断非常多嵌套又非常深.可能看SQL文就得一上午的时间. 2.采用 List getUsersByUserName(String name); List getUserByRoleId(String name,String roleId); List getUserByDept(String name,Stirng roleId,String dept); List getUsersByUserName(String name){ if(name == null || "".equals(name)){ throw new IllegalArgumentException("请检查参数列表"); } } List getUserByRoleId(String name,String roleId){ if((name == null || "".equals(name)) && (roleId == null || "".equals(roleId))){ throw new IllegalArgumentException("请检查参数列表"); } } 通过这样的实现可以从方法名称上知道我要的是什么数据.同样维护人员可以在方法名上得知我这些参数组织起来后会得到一个什么样的list,和主要条件 问题是,会产生很多这样的方法.而且名字通常不能表述完全我需要的参数.关键参数需要在程序里面验证. 3.使用List getUsers(User obj){} 加注释的方式 /** *user.userName = "tom" && roleId = "employee" = 查出 所有叫tom的员工 *.....其他组合方式的注释 */ List getUsers(User user){ } 知所以出现这样的疑问是为了代码可以更好的被维护,也可以大量节省维护人员的时间。之后无论是别人使用方法,还是维护人员查看代码都不需要去下面找SQL文,面对里面N多判断.在脑子里面组织出自己想要的条件. 大家有什么意见?请多指教~ 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-06-27
我现在用List getUsers(Map<?,?> map){} + 文档或注释。
可以维持接口统一,并保持接口简单。 用map可以表述很多user对象本身表述不了的东西,简单的如MYSQL的limit,而且iBatis对map的支持相当好。 方法二,一方面会照成接口臃肿。另一方面,方法名本身携带的信息很有限,简单的也就算了,要是复杂的查询怎么办?还不如直接留个详细的文档给维护人员。 嗯,这个问题仁者见仁智者见智,我占个楼,看看大家的想法,多多学习,呵呵。 |
|
返回顶楼 | |
发表时间:2008-06-27
我在项目中一般这样做
每一个SQL都对应于详细设计书(excel文件)的一个sheet相对应 在设计书中每一个用逻辑名写SQL 在Dao的方法注释中通常只需要把sheet名称copy过来 |
|
返回顶楼 | |
发表时间:2008-06-27
MonkeyLin 写道 方法二,一方面会照成接口臃肿。另一方面,方法名本身携带的信息很有限,简单的也就算了,要是复杂的查询怎么办?还不如直接留个详细的文档给维护人员。 是呀,我们尽量把这个方法所得到数据的过滤粒度写在方法名上,其他的要靠参数来控制,如果参数实在是多,就要使用VO又回到方法1上面。开这个帖子是希望知道大家在面对这样问题时的想法和解决方案,当然也可以对我的三个方案提出宝贵意见。 我们都想写出容易维护的代码 |
|
返回顶楼 | |
发表时间:2008-07-03
这种情况需要在DAO的接口方法中进行详细的注释,VO对象也将限定前台开发人员能传递的参数范围,同样,根据DAO接口方法的功能介绍,前台开发人员也能够很容易的知道自己传递什么样的参数就应该会出来什么样的结果
|
|
返回顶楼 | |
发表时间:2009-05-20
如果说输入的参数 有可能 不同,及输出的结果也不确定呢?? 还要一个一个字段定义 出来么??
|
|
返回顶楼 | |