1“form主要是封装表单数据的”
----正是因为form里封装了数据，所以它才要实现业务逻辑的。
反之，业务类的方法与form内的数据产生的狎昵关系，一定会被转移到form里的。
2“当然不行,它只是数据存储.
如果还想负责业务逻辑,
那就要实现控制功能了,
控制器会根据业务逻辑来实现转发的,
像你这样功能就没有净化,耦合性太强了
”
-----------如果form只负责“数据存储”换而言之：你想让它成为单纯的“数据类”。结果 就 是：form和其对应的业务类更加紧密的耦合了！
----------耦合性？**和**的耦合？？？
----------“控制器会根据业务逻辑来实现转发的”？错！控制器不应该参与业务逻辑的。
也就是说:作为控制器一部分的action只应该完成业务逻辑的调用。我们这里讨论的是：“业务逻辑由谁完成更合适(form还是form委托的其他类)”。
----------“像你这样功能就没有净化”，业务功能无法净化，功能由客户决定。
----正是因为form里封装了数据，所以它才要实现业务逻辑的。
反之，业务类的方法与form内的数据产生的狎昵关系，一定会被转移到form里的。
2“当然不行,它只是数据存储.
如果还想负责业务逻辑,
那就要实现控制功能了,
控制器会根据业务逻辑来实现转发的,
像你这样功能就没有净化,耦合性太强了
”
-----------如果form只负责“数据存储”换而言之：你想让它成为单纯的“数据类”。结果 就 是：form和其对应的业务类更加紧密的耦合了！
----------耦合性？**和**的耦合？？？
----------“控制器会根据业务逻辑来实现转发的”？错！控制器不应该参与业务逻辑的。
也就是说:作为控制器一部分的action只应该完成业务逻辑的调用。我们这里讨论的是：“业务逻辑由谁完成更合适(form还是form委托的其他类)”。
----------“像你这样功能就没有净化”，业务功能无法净化，功能由客户决定。
旦如果是这样Form.setBusinessLogicClass(businessClass),或者在form里获得业务逻辑类的话“责任的划分”就比较清晰了：jsp表现，severletControl+action控制转发,form实现业务逻辑的转发。
这样也带来了另外的问题：form要不要拓展业务接口?一般来说一个form可能完成若干业务，它的写法就会成这样：
**Form implements Logic1,Logic2**{
private Logic1 ConcretLogicClass;
private Logic2 ConcretLogicClass;
***;
}
个人认为，这种做法才是较为优良的设计，但是唯一不足的地方就是产生了太多的业务类！难以维护。
之所以呼吁“业务逻辑在form里完成”，就是想牺牲一下“解耦”，抵消一部分代码量。
但对你提出的几个观点，个人的看法是：
1，struts本身的定位主要就是解决表示层的问题，用它来处理业务层以及持久层并不妥。
2，我个人认为form并不是作为M的姿态出现的，它的字段与view是吻合的，在并不复杂的业务当中它与Model会很相似，甚至一致，但这种情况只会是相对简单的业务下发生的。所以我更倾向于把它理解成Context Object模式，它的主要目的是用来降低页面与业务层的耦合。然而在相对复杂的数据模型当中form是无法起到取代Model的地位的。前面已提到，struts是作为表示层的姿态出现的，以它来处理业务，个人认为并不妥。
3，如果诸位认同我第2点的看法，那么楼主接下来提出的疑问已经不是问题了。纯属个人观点，水平有限，欢迎拍砖！
1,不利于v和m的分离,代码混乱,不清晰.
2,不利于模型层代码的重用.
-----显然，你认为form是v的一部分。这一点上咱俩已经从根本上出现了分歧了！v作为m的表达，“字段吻合”显然很正常，旦这不是form in view的根据。
---好了，加班完毕，明天接着说*****感谢你们，我用一肚子的纯情*********
是的，这个问题也许看起来比较愚蠢，其实我是想通过它得出一个“业务逻辑”在何处实现或者在何处调用跟为合理的论点，从而得到一个较为合理的设计。
我做struts两年多了，一直在使用公司的平台开发。这里“持久化”是由一套封装较好的DATA控件完成的，我只需要在“业务方法”里调用addRecords()、delRecords()、update()等等即可完成数据的操作，所以持久化不是问题，至少对我来说是“轻量级的问题”，我关注的是/action/form/“业务逻辑”的设计，通过对此的探讨，得出一个规范性的设计方案，解决目前系统中编码混乱、维护困难的现状。
如果jsp展示、action转发、form仅仅作为“数据的持有者”，那么我们的“业务逻辑”由谁调用都是问题。我比较认可form作为“组织者”的看法:form本身不处理业务，但它需要调用业务完成数据的改变。这样一来action只需要通知form需要改变数据并完成转发（多半是返回到请求来的页面）,form调用业务处理完成状态的改变；jsp根据form的状态表达出来。
但是作为底层的程序员，面对的是成“千上万条”多变而具体的业务，我们无法依赖于抽象把各项业务封装的干净利落，很多时候我们只能抛弃业务接口的实现、而直接使用某个方法实现该项业务------一旦业务有变化那我就修改form里实现业务的类即可，----虽然它彻底违背了单一责任原则，但权衡一下代码的量（可以用成本衡量）我还是这么做了-------我亲手让form成了God！----吃饭了,待续!-----
-----------那我该怎么做？你是怎么做的？迷茫的我一脸真诚。
-----------我关注的是设计，是想通过设计解决一些问题，java语言的出现已经超越了工具的层面，它用较为纯粹的手法改变这程序设计的思想。某语言好不好用，在于你对它的理解，以及对具体问题的分析。
------------之所以我这么固执的求解，就是因为我面对的是“想怎么用就怎么用”生成的一大堆混乱的代码----这也是“项目僵死
”的主要原因。也许这也是咱们必须严肃看待的问题：如何作出合理的设计。
------------敏捷、模式、重构、j2ee模式等等都从不同的角度入手最终给出了优良的设计模型，无非设计模式的应用。（当然这是优良的）。现在我们讨论的是：struts这个表示层优秀的framework里如何设计model，当然前提是我抠除了EJB。
------------struts in action 里有这么一段：“因为它可以和业务逻辑 bean进行交互, ActionForm通常可以使用业务逻辑bean中的一套相同的属性名称。通常，这些属性间并没有相关性，所以这不失为一个很好的实践方法。虽然form bean和逻辑bean最终都是表达相同的数据，但是它们在各自的生命周期内表达数据的不同视图。逻辑bean表达的是模型的状态。form bean表达的是状态的改变。ActionForm bean收集和校验输入。业务逻辑 bean处理捕获的数据并将新数据合并到模型中。”
我想省了业务逻辑bean，把所有的工作交由formbean去完成----这么一个折衷的方案。
因为：我可以严格按照职责的划分作设计、写代码；但是我无法要求他人也这么做，别人似乎更愿意在action里完成业务处理----每每读到这样那个代码我几乎都要昏厥。都退一步，在formbean里完成业务逻辑，这样一来即便是将来程序重构，我们转移这些“业务处理”仅仅将formbean的“业务方法”委托给“logicClass/bean”即可。
------------能不能把直接指出目前我这种做法，潜在的“危险”，多给点讨论（或直接给出更好的方案）而少给点蔑视与不屑？（不是针对“jxdn_yang(张婷)”，女程序员稀有，理当爱惜:P）
因为这里才划清了在form里完成业务逻辑的界限。那就是：
1，较为简单的“业务逻辑”。2，持久化不是问题。3，面临的是轻量级的问题。
有了这3个为前提，在form里完成业务逻辑是完全可以的。我持赞成态度。这也是struts in action在为设计actionform时提供的策略之一：由form来实现业务层接口。
引用原文：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
业务层通常为其中的bean定义接口。当一个业务层接口可用时，你可以使你的 ActionForm
实现该接口，以便它可以直接传递到业务方法:
public class ArticleForm extends ActionForm
implements ArticleBean {
// ...
}
然后，在你的 Action中, 你就可以直接传递经过校验的ActionForm到那些需要业务层类型
的方法:
articleModel.save((ArticleBean) form);
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
这也说明，设计没有对错，只有合适与不合适的区别。在你给出的前提下，你采取的这种方式应该是比较合理的。
PS：我也是03年接触的struts，多多指教。
。
结果就是：“肮脏的代码”充斥整个系统，修改困难，维护困难、两个模块，两个人之间的易手难上加难；加之写代码“不自律”，bug层出不穷，工期一拖再拖，一出差就是好几个月，娘的--累了。重构里一再要避免的问题我每天都要面对！------泪水。
都说“好的设计加上差的代码 = 可用的软件”，那么“合适的设计+中等的代码”会不会也能提高一下生产效率和工作热情呢？呵呵。
好了，继续关注：又他娘的上班了。
程序也是如此，把业务的设计和实现统统交给最底层的程序员去处理，又不加以规范，那么就像一支球队把中场组织的重任交给了一个我这样的草包，输球是必然的。
不知道其他公司的其他系统是不是也这样：做好一个framework或者弄上一个基础类库，再草草的弄回来一个需求，ok！开发把你！！
到了现场，先开上上个把月的会，你和客户吵啊吵啊，终于你被客户整挺了，客户说鹿就是鹿，说马就是马。针对程序客户给你提出了3013各问题，个个问题都打到你的软肋上，你整理出来2847个------客户说：你态度有问题！于是问题的个数变成了：3012个。
这些问题颠覆了你对需求的理解，也颠覆了你的设计，还有一些明显很不合理，这时候你还要留一手：作出一个合理的，等着客户醒悟过来。
说到开会，你怒了，你知道除你之外，来到桌上的都是领导，是领导就有激情，是领导大脑就会充血。领导a说：这个功能我们要这样做！b说：这样不行我们要那样。最后大领导拍板了：原功能保留，但是这样行，哪样也得行。ok，今天周五，星期一我们看，散会！
你无语了！周末你拼了，那还将什么设计呀，那还顾得上程序的优雅？！终于你应付上了，交给他们，你认为这下应该满满足了吧？！谁知道一阵指指点点后，大领导一拍板：恢复到原来把！你再次无语。
客户向来都是这样喜欢做“激情需求”的，你必须对业务烂熟于胸，你必须对业务比做过的还做过。
由于问题多多，程序上线推迟了一个月，项目经理很不满，你胆战心惊的做你负责的模块，你发现给你一年差不多。你丝毫不敢松懈。这时候你想起来了：程序需要优良的设计。你对经理说：我们的模块间应该解除耦合，经理一脚把你从29楼踢出去。你对小弟说：我们应该面向接口编程，小弟很委婉：你怎么不去死？。
-------牢骚先发个半截。
于是赶工赶期，投入战斗，你心里明白，大家都在写代码，都在创造垃圾，唯一不同是将来维护的重任可能离不开你，也就是说：大家一块拉大便，但是你负责擦屁股。（原谅我这么粗俗，我现在无法平静）。
综上所述，才有了我那“在form里完成业务逻辑有何不妥？”这样愚蠢又严肃的问题。