关于struts2的验证问题

Struts2 Validation有两种方式：
第一种，实现Validateable接口，validate方法；一般我们Action extends ActionSupport，重写validate即可。
第二种，通过Annotation（好像在2.1版本后不推荐了，详见 http://struts.apache.org/2.x/docs/validation-annotation.html）或validation.xml配置方式实现。

实现机制是，默认拦截器中有个前置拦截器validation interceptor，会执行上面的验证，在拦截器栈的最后有个workflow拦截器，如果有验证错误的话，直接跳转到错误页面（默认是INPUT页面，也可以通过InputConfig Annotation配置），不执行Action的业务逻辑。

设计的想法是很好，但是目前有个问题就是（楼主也提到些），这两种方式只能对所有方法实现相同的validate。不能区分不同的方法，不同的验证。


目前我想到的一个折中的实现方式是，自己通过业务方法实现业务逻辑验证，把错误通过addActionError/addFieldError保存起来，直接跳转到错误界面，通过<s:actionerror/>和<s:fielderror/>标签显示错误信息。

大家觉得这方式怎样？有什么优劣？

硬代码太多，不方便维护

直接调用验证工具的意思是用其他的客户端验证工具，比如说jquery.validate?

是的，就是这个意思，一般这些验证，都可以自己做一些方便的工具。

 

比如:

form.submit提交前，遍历所有的input：

 input需要验证的，执行验证，不通过标示错误信息

 

以上都可以通过客户端js达到。

 

    这是一个解决方案，有一点感觉就是既然有了，就再去搞一套，也挺麻烦，需要维护两套，客户端一套，服务端一套

这个问题我也一直纠结过。

一些mvc的框架基本上是在server配置验证--(就是为了自动生成js验证脚本)，如果自己手写，是不能的。

验证统一一套的可能性：
    服务器验证和客户端验证，因为不是同一种语言，所以弄一套基本不可能。
(听说jvm可以运行js，呵呵没尝试过)

服务器验证是必需的：基于安全的角度。

客户端验证也是“必要”的：
  1. 好的客户体验
  2. 减轻服务器压力

 

分别维护客户端（js工具）和服务器验证（工具方法）后，发现开发越来越快，避免了以前使用框架带来的问题：

 

1. 框架验证配置和代码分离，查找费时，稍微不注意就漏掉了，而直接写代码，任何人都可以看懂，便于维护，不易忘记。
2. 避免为了框架而框架：框架不能满足要求时，需要查找按照框架来的解决方法，往往需要很长的时间。
3. 平衡考量：框架是通用的，而项目是个性的，注定了他们是矛盾的，框架只能向项目这个环境来演化发展，那么必将越来越个性。验证简单的可解决，但是遇到项目逻辑的验证，还是要自己写，还不如自己累计。