说到这里，写Hibernate框架书的也有这个问题。书上介绍的是框架，但是有时候对如何在项目里正确使用框架没有写。造成很多人在Dao里写业务代码。
最后两边把Service层的功能一分，三层架构变二层了。Service里除了一句Dao的调用代码，什么也没有了，典型伪三层结构。
你的思路非常好，Action的作用是很小，但是不能和Service/Action合并在一起，因为Action属于表现层 而Service属于业务层，多层架构不能破坏，否则又回到两层的Delphi时代。
那有没有又不需要Action，但能保留Action的方式呢？有，Jdon框架2004年就做到了，也就是不需要写Action代码，但是可以配置Action，这样达到两全其美。
当然，相信这些老外技术除了走上述国人Jdon框架这条路，还有其他更好的路可以解决上面两难问题，拭目以待。
关于两全其美的办法，我现在是采用只写一个action,然后动态调度该执行那个具体的service。因为绝大多数页面的action都一样，如果以后有需要在添加新的action类型；总的来说就是把action分类，而不需要为每个页面都写一个action,banq大哥你觉得靠谱吗？
Jdon框架强制你对系统进行分层，aciton空壳，编接口和实现，然后配置组件让容器autowiring，要服务自己到容器里面去取。建议初学者把Jdon学一下先，如果直接用seam这些注解类框架，谁教你分层啊？
对的啊，jdon框架也是这个思路实现的，真理总是站在善于思考人这边，软件永远只是思想的结果。
关于seam框架，在它一出世我就说了，乖乖，把Ioc发挥到极致，到底是外国人，剑走偏锋，出奇制胜。其实Seam这种Ioc方式，就是国内某个大公司框架自我吹嘘的IoVC。
Seam这样做，好处当然有，但是缺点很显而易见，多层之间本应相互解耦，结果现在可能适得其反，你可能在Action中耦合持久层或其他非业务接口的代码。因为你总是要在代码中提供注射通道，打个比喻，两块木块要连在一起，不管是谁先主动发出连接对方（这些都是连接方式IOC/DI解决的就是连接方式），总是要在一个木块中开个凹槽，另外一个开个凸槽，这样凸插入凹就是注射通道。
为什么Action不能耦合太多代码？
首先从修改维护性上考虑，Action本来就是一个前后台调度的调度者，将前台用户输入传递到后台业务处理，将业务处理结果再传递到前台界面，Action就是一个二传手，说文一点，是Mediator模式实现，二传手就是二传手，不能充当前锋，也不能充当主力，这就是分工。
再打个比喻，警察在十字路口指挥交通，这个警察就是Action，这个警察职责就是调度指挥职责，不能将其他更多职责给他了，否则就违反OO设计原则。
所以，从这个意义上讲，我们将Action低调化处理，不完全消灭它，让它只出现在配置中就可以了，在这个配置中，它完全发挥了调度指挥事件流的作用。
请问能给出一些具体配置和代码吗？
可以看看Jdon框架中的ModelSaveAction类。
一个是service的名字e.g.: login自动加上Service--〉loginService
第二个是这个service的方法名，参数没有的话有默认处理；
靠这两个参数定位到service里面的一个具体方法。
页面上的值都存储到一个dyncDTO类里面，这个是个HashMap,共通的action直接把它传递给service。
例如：
login
login
我明明可以写一个OperateService来完成业务作业，而在action中@In OperateService的。
简化是个诱饵，但是seam的好处不仅仅在于这惟一的简化，还有其它的好处，比如权限处理更加简单，Observe更加简单，只需要用注释来注册它即可。