webwork开发误区。

最近做了一个不大不小的web项目，开发过程中发现很多不合理的地方，，趁着有空做一个小小总结：
1）webwork的易测试的损害
这点，是我的设计最经常犯的愚蠢的错误之一。本来webwork以易测试出名，然而在我的设计中老是提供了servlectContext的侵入。一个最普通的例子是生成静态文章的html。因为要顺便生成html的href，而href我自然而然的使用到了ServletContext的path。在业务逻辑中加入了这个功能之后，使得我的单元测试困难重重。
结论：慎用ServletActionContext！
2）尽量使用ognl。
   ognl无论对于session使用量的减少，还是增加代码的整洁度，都是至关重要的。使用了webwork而不使用ognl，那就说明你没有很好的理解webwork。
结论：让ognl做完你的action中大部分与web提交相关的操作，而不需要你自己手工去写代码。
3）ognl对于参数赋值的顺序。
    一些参数的赋值在应用中是需要先于其他参数的，比如更新操作中Id的赋值。这时webwork提供的默认拦截器并不符合规范，可以覆写。


4）action设计的两面性。
    从action中分离业务逻辑导致两面性：1）层次分明 2）代码量增加
    较为简单的web开发中，action设计的两面性比较突出。
    虽然设计action的宗旨是尽量保持其简单，然而，将业务逻辑封装在action中并不见得就很错误，至少从代码量来说，它很划算。另外，虽然增加了测试的复杂，但是webwork使用ExternalRefResolver依然提供了良好的可测试性，从这点来说，依然能够保证易测试。
结论：可以封装简单的业务逻辑在action中。

如果不使用servletActionContext,如何设置cookie哪?

(初学问 )

ServletActionContext.SESSION(REQUEST...)
没问题。
但是应该少用。
可以考虑分离web逻辑，业务逻辑。
测试---〉业务逻辑
web逻辑尽量简单---〉web(action webwork测试框架)提交测试

好人

这个观点是非常错误，除非你能肯定以后不再维护这个应用（主要指添加新的功能）。如果以后要维护的化，必然要将业务逻辑从action中分离出来。不然那将是一场灾难。我刚辞职的公司原来就是把业务逻辑写在action里的（我们用的是struts），后来添加很多新的功能和新的逻辑，由于没有重构（将业务逻辑从action分离），action中的代码越来越多，导致action中的代码逻辑很复杂，而且根本不能重用。在我走之前boss说这个季度要下定决心重新设计以解决这些问题。

action何以要重用？

我想他应该是说业务逻揖不能重用吧，由于大量的业务逻揖放在Action中。

yes

可以做一个cookie interceptor

你们的boss管的可是细到家了 这话应该是XX人管的 而不是boss的职责