各位大哥，小弟想问下，在三层架构中的复杂条件查询时怎么实现的呢？我的意思是说数据访问层并不知道客户层传来的参数顺序或者说当条件更复杂的时候，应该怎么办，用Map

问答首页 → Java企业应用

0 0

各位大哥，小弟想问下，在三层架构中的复杂条件查询时怎么实现的呢？我的意思是说数据访问层并不知道客户层传来的参数顺序或者说当条件更复杂的时候，应该怎么办，用Map5

各位大哥，小弟想问下，在三层架构中的复杂条件查询时怎么实现的呢？我的意思是说数据访问层并不知道客户层传来的参数顺序或者说当条件更复杂的时候，应该怎么办，用Map传似乎不能解决问题，将条件再封装成一个对象似乎可以，请各位指点迷津！！

DAO

2009年12月18日 09:11

yf86810_163_com
20
0 0 0

2个答案按时间排序按投票排序

0 0

不建议使用map，还是在控制层使用一个POJO（Plain Old java object）将你的条件进行封装吧，这样代码的可阅读性会比较好。
实际上很多框架都是这样做的，如struts就是将提交的表单映射到一个Bean中，struts2就可以将视图层传过来的参数直接映射到一个Bean的属性。如果从视图层传过来的数据是要存储和更新的，我们将封装的POJO称为DTO（Data Transfer Object）；如果传过来的数据只是用来做查询条件的，我们称封装POJO为VO（Value Object）。

2009年12月18日 16:45

Heis
112
0 0 0

添加评论

0 0

你的问的不单单是一个问题了
## 设计方面考虑
1. DAO是属于数据访问对象。
   [最好别在其中加入业务色彩] 这种思想是为了提高DAO复用性，
   DAO的入参和功能都应该尽可能的简单直观。返回结果则是 [数据传输对象]
2. 业务层面负责数据访问的调用，需要首先对 [业务数据传输对象] 进行解析 ->
   调用数据访问功能 -> [数据传输对象] -> 组装成 [业务数据传输对象]

## 开发复杂度和性能上权衡
1. 根据项目复杂层度权衡 DAO -- Service,
                        Service -- Action,
                        Action -- view
   之间数据交互对象复杂层度。

2. 复杂查询基于业务复杂度，往往会打破三层架构的初衷，在DAO中加入业务色彩，
   复用度很低。
3. 复杂查询往往牵涉更多性能问题，需要考虑 DB 中 Table 的设计。
   例如：
        查询无法使用一次sql完成，则会演变多次sql执行。
      （问题：SQL语句优化策略，
              考虑分步执行的必要性，
              数据与程序交互的数据量，
              是否应该使用存储过程，
              是否应该把部分计算压力，从数据库转嫁到应用服务
              [ps:毕竟只是是数据的仓库，但如果 DB 很强则就别浪费资源]
        ）