Action 与 form 的职责划分

面向对象的第一个原则既是：“单一责任原则”。在兼顾程序的易读性与业务复杂性的同时，作为最底层的程序员我们不必把每一个责任做一个类。于是只剩下责任划分的问题，即：业务由谁来完成：action 还是 form。

比较：

1．              从MVC-STRUT框架来看，action 有时和jsp一起归为“view”，响应客户请求、有时干脆作为“控制器的一部分，于模型交互，执行状态改变或状态查询，以及告诉ActionServlet 下一个选择的视图”（《struts in action 》，第二章, 本人倾向于这张看法）。但无论action 怎样摇摆，他都不会作为model出现---------完成model责任的只有form（或者一起捆绑在form上的其他类）。

2．              Form作为“纯数据类”的不可取性。“纯数据类”的出现本身就带有结构化编程思想流毒（structure 比 class 做得更好，更干净）。如果这样，那么action处理这个啥活都不干的“纯数据类”的时候，他要从form里，把“属性”一个个取出来，在干完form该做的活，再将结果交给form。那么，action里的这个方法就和form出现了“狎昵关系”。这种“狎昵关系”造成的后果就是：代码冗长、程序难懂。

3．              Action自身的缺陷。在struts中，他的责任非常明确：转发，仅此而已。他没有真正意义上的 “属性”。它的接口已经固定（参数）（你可以写一些private方法但那不是接口，当然也与“业务逻辑”不相干）。它是一个“变态”的类，它产生的业务逻辑表面现象是：程序不用“跳来跳去”的看，实际上他向结构化方向上的倒退，造成的冗长和众多的bug远远大于它的“直接”-----的确，某些习惯还在影响。可以说：喜欢这么些代码的程序员，对自己的代码也不喜欢负责任。

4．              扯远一点，理论上我们的form也不应该处理复杂的业务逻辑，它只应该“加工数据，把action解放出来”即可。更复杂的业务逻辑应交给ejb或者“存储过程”去完成。可是我们的系统面对的是“成千上万” 个“业务逻辑”，每个“逻辑”都有一个类去完成，再算上与之相关的“逻辑的接口(interface/abstract)”，那么我们程序的体积将扩大一个数量级-------这不是一个值得期待的结果。
所以需要有一条中庸之道即“把业务逻辑交给与之紧密相连的form”。

5．              业务逻辑与持久化：显然二者分开来做，是一被提倡的。这是因为，持久化本身是一就项复杂的工作，与业务逻辑掺杂在一起会让程序变得混乱。在这种情况下，分开来做显然是一种“明智的选择”。然而，咱们的DBTool/ClientDataSet，已经把持久化工作降到最低，与数据库的交互不再是影响业务逻辑实现的负担。（就是说highSoft framework的特长就是“持久化”），我们的ClientDataSetForm已经比较完美的实现了数据的交互，我们还有必要在form里引入其他“业务类”做咱们的实现么？

6．              再扯远点，我们看效率。Action 最终会变成一个一个的线程，常驻在服务器内，对于“活着的线程”应用程序必须为它准备资源。Action 大量创建的“大对象”必须常驻服务器的内存。而form只在“请求”来到的时候创建一份，用完马上清除。----效率高底一目了然。

7．              题外话；action 处理业务的时候，“方法”命名都成问题：java规范中明确要求“方法的命名应该表达‘做什么’”。现实中一个“按钮”往往会“做”“多个什么”。于是，只有在action里拼命加注释！（当然，现在‘注释’也不被提倡）。

    其实，明眼人和有些java常识的程序员，都应该清楚“责任划分”的重要性，这个问题本来就不存在讨论的意义。

。。。。。。。。。。。。。。