先看原文.
http://computer.mblogger.cn/sassc/posts/13205.aspx
我们公司有位同事也喜欢用这种模式来处理.
个人感觉这种模式就是舍弃了Action,Action仅仅用来反射调用ActionForm中的逻辑方法和进行转发.
我觉得ActionForm中仅仅是保留值对象和进行一些数据类型检查等方法.而业务逻辑应该放在Action里面去调用逻辑层.
而且按照上面的做法,逻辑层和ActionFrom耦合在一起.感觉有一些杂乱.而且在结构和层次上也不如ActionFrom--> Action--> Business-->DAO......这种模式清晰.
想听听大家的意见,希望BANQ大哥也来发表下.呵呵.
(本人属菜鸟,说的不好的地方请见谅!)
多谢，这种用法是来自Jpetstore 4.5 的IBatis版本，可以下载来看看作者的说明。这是一种怪异的用法，本来想追求类似JSF，或者做一个完整的非贫血的边界Model。
将Action功能放入ActionForm，倒退到以前Jive 2.5源码的水平，也没有充分考分线程安全，而且这种用法必须配合单例模式，更是在多线程下危险。
从设计上说：就是foxty说的还是过分耦合，这个问题和以前讨论的贫血模式一个道理，是将Service功能从Model中分离；还是两个混合在一起？从模式角度看，Action和ActionForm其实是一种桥模式实现，以达到更灵活的运行配置组合，象IBatis这样做无疑是阻断这种灵活性。
IBatis作者只是一个持久层专家，但是他要倒插一腿干涉到表现层和组件层，这点不如Hiberante的作者智慧。所以看JPetstore，最好看Spring的Jpetstore和Jdon的JPetstore，我在Jdon JPetstore中将IBatis从持久层伸出过长的手全部砍掉。
多谢banq大哥的意见,受益不少.呵呵!
个人也觉得这么做灵活性受约束.
另外还有个问题:
我再设计项目持久层(IBatis)和业务层的时候,底层全部统一DAO接口,对数据对象的CRUD,其中包括一个select操作是允许动态加入条件参数的.这样可以满足前台业务的不同需求.然后其他的业务全部放到业务层来做.
公司的一位老员工带来的经验却是,每个底层实体映射都做了一个接口.而且对于不同的业务操作提供了底层的DAO接口..然后逻辑层只是去掉用这些底层已经配置好的操作来实现.
我觉得业务逻辑带入倒了DAO是种不好的做法,如果业务逻辑更改了,那么还需要去更改底层的映射配置,又是增加耦合度.
不知道各位都是什么想法?欢迎套加入讨论.:)
我现在倒退了，喜欢把业务逻辑用pl/sql来做，业务逻辑改了，就去改存储过程。可能是因为自己pl/sql用熟的关系吧，个人感觉比较省事。这样控制层，和DAO里就非常简单了。且重用度极高。oracle 的workflow 就是这么做的。业务逻辑全都pl/sql实现。
层间传递，用数组，一步到位，简洁清晰。效率也高，还便于分工合作，联调。
表示层用了一部分标签，感觉虽然四不象，呵呵，但是最贴和实际。当然大家若是搞研究，提高自己的境界，认真较较针，还是有好处地。