Action直接调用DAO的查询方法是否合适？

我们使用设计模式,是为了代码更好的重用性,结构更清晰,我从来不觉得模式会增加我们设计的代码,在同等灵活的情况下,我们的代码会更加得节省的

除非是画虎不成反类猫，否则用了设计模式，代码一定会减少。

你们没有明白我的意思。在不需要变化。不需要灵活的，一个人几天就能搞定的项目中。直接用jsp绝对是最合适的。

我有点不太明白，有人能再说清楚点么？
“action通常是调用业务层的控制类”
业务层的控制类指什么呢？

如果业务简单的话，比如：只是把数据库中的表显示在页面上，那直接调用dao有何不可？至于以后...，那就等以后再说了，谁能预料到呢？

的确我也有过如此的困惑。增加一个业务逻辑层的主要作用有以下几点：
1、可以清晰系统架构分层，降低耦合。使得表示层Action毫不关心数据访问层(DAO)。
2、DAO层中的方法不含业务逻辑，是原子的数据访问方法。提高数据访问方法的重用性。
3、业务逻辑复杂的情况下，业务逻辑变化，对系统影响很小。只需要修改SessionBean中对dao方法的组合就可以了。

当然在一些简单的业务逻辑的状况下，是SessionBean方法与DAO一一对应的，但是，这种架构处理复杂业务逻辑就显示出上边的优势了。我们的一个财务管理项目的开发体现出了的优异性。

显示逻辑是指请求一个视图，或者一个业务逻辑执行完毕后，定向一个视图，这都是显示逻辑了。
业务逻辑自然是指用户发出一个command，做的一件事情，如果这个事情不是显示逻辑，那么就是业务逻辑了。往往，业务逻辑代表了用户发出一个命令要真正执行一个操作。
那么这里Action类的职责就是一个Controller，及业务请求转发与视图导航。各层各司其职，分工明确，代码清晰可控，甚至便于编码的分工。