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

Struts+SessionBean+DAO+Hibernate下，Action直接调用DAO的查询方法是否合适？

明确你采用上述结构的目的，比如为了应对变化，为了解耦，为了学习，为了开发分工。。。
你在action里面采用查询方法是否会违背上述目的，
如果判断不出，就看dao的查询接口是否稳定，还判断不出，就直接调用，准备重构就是了。

不合适，Action的作用就是调用业务层的控制类，不应该在Action里面写业务逻辑代码。

上午比较仓促，写的太粗。举个例子吧，比如用户管理里面，要修改用户资料，先要把用户列出来给操作员选，或者先显示机构树，选择机构以后列出机构下的用户，操作员选择了用户以后可以对他的资料进行修改。这里就涉及到了一些纯粹查询的方法比如getAllUsers()、getUsersOfOrg()，DAO可能已经提供了这些方法，SessionBean还一定要原封不动的再加一层封装？这里提到的查询都是相对独立的查询，并不是事务处理过程中的查询，是不是可以不当作业务逻辑看待？

理论上来说Action只应当做为调用业务层逻辑的一个客户端代理，不应该在Action里面直接处理业务逻辑。你的例子中业务虽然简单，但是仍然是业务逻辑，虽然现在非常简单，你可以直接写在Action里面，但是如何业务以后复杂了，你就需要不断的修改Action里面的代码，Action会越来越臃肿。这就不如把业务逻辑代码和Action分开，有利于应用程序的可扩展性。

不过话说回来，理论是一回事，实际应用又是一回事，你可以根据自己项目的需要灵活的进行取舍。不一定非要遵循，重要的是对自己的项目开发有利就行了。

说来说去，可能是自己对显示逻辑和业务逻辑的界限还是不很清楚

如果不在action里调用在哪调用呢？在sessionbean里？

我想大多数开发者都是在Action里调用Bean里的业务处理方法的，如果不这样的话也可以提供接口服务，直接调用接口方法即可，其实现在Bean里就可以了，其实我就是这样作的！

斑竹说得不错的，action是一个实现control的地方，要是引入了bussness，等于你设计的层次结构都白做了
虽然好像代码更为的简介，可是阅读性和可修改程度也变差了

你没发现只要用了设计模式就比直接用jsp实现代码量加大了很多。
如果你只是想把功能实现。那你还考虑什么。用jsp好了。
可关键是代码少了就会更好吗。还是根据自己的实际情况衡量一下吧。