是否需要验证值对象的合法性，如果需要验证，在那里验证合适呢？
望高手指教。
例如 ：class valuesObject {
public int getCdNum() {
return cdNum;
}
public void setCdNum(int _cdNum) {
这里 _cdNum 必须保证 〉0,是否需要在这里验证,
如果不需验证，那如何保证构造的值对象的合法性呢？
如果需验证，那是在这里验证，还是在其它地方验证？
cdNum = _cdNum;
}
private int cdNum;
}
在输入时验证，例如Struts的ActionForm中
验证实在也是个比较麻烦的事，验证能否重用？验证是否能与业务分开？怎样使得业务逻辑不被一些琐碎的验证肢解成了ugly code？
在展现层（如，Struts,tapestry等等）的验证总归是不能解决业务深层次的验证，我认为也不能让业务的深层次验证提到展现层来验证，那样违背了MVC的本意。
实际上，验证的规则是有章可循的，无非最大，最小，不能为空。。。。。。等等，所以其重用也是可能的。Vlad框架做到了。
验证又怎样从逻辑中剥离呢？ 这其中实际上就涉及到AOP（面向方面编程）技术了，作为java程序员，java似乎目前AOP特征一般，我们就不能做了？ 不，还是可以做到的。nanning是一个非常优秀的基于Java的AOP框架。
那么，结合两者，我们的验证代码和业务逻辑是分开的，前者不污染后者，使得code smell good，验证又可以重用的情况使得我们的code smell very good.
我已经在一个期货系统中作了具体的应用---纯净的代码。
详情请到http://www.erproad.org上参阅，我将在未来的日子给出一个较好的解决方案。
其实，关键就是对于Bean的验证
struts的dynmaicForm是可以通过xml定义验证项目，非常方便，只是目前有一些小bug.
其实你说的依然是bean的验证，对于struts的验证框架我也稍有涉猎，在去年的一个项目中，我也曾经应用过Struts框架。
如果让我说这个验证框架的好坏不如说Struts本身过程式的开发方式限制了其自身的许多本该突显的许多优点。
方便是一方面，重用则又是另外一方面。 我想，没有组件式的编程真是不可想象的。
struts做不到，也不可能做到。 我曾经在Struts上为重用一个多入口以及多出口的页面伤透脑筋。 最后还是用logic tag解决问题，但这和传统过程化编程有什么两样呢？
一点拙见，勿怪。
struts的验证没有管理filed之间的交互关系
即使管理的，也是有一个欠缺
比如，页面上要求，选择了a，那么bcd就不用填，否则，bcd必须填
目前只能用javascript自己写来实现这样的功能，绝对ugly code
楼上的另一位提到的网站等下就去看
目前我的想法还是用xml来描述规则
然后自己写一个引擎来生成javascript代码，完成功能的简单描述：
当选择a，把bcd改成disabled
这个文章还是很有意思～
weihello有msn或者qq嘛？
呵呵，我现在在准备出一个类似的规则检查的引擎（不过也要等前期结构设计完先）
或许，可以从你那弄点现成的呢？^_^~~
其实，这框架不要写了。Tapestry就现成的，javasrcipt可有组件。
Tapestry还是没有能够解决问题，只是一个类似taglib的方案
javascript现成的组件可有指明道路？;pp
验证实在也是个比较麻烦的事，验证能否重用？验证是否能与业务分开？怎样使得业务逻辑不被一些琐碎的验证肢解成了ugly code？
在展现层（如，Struts,tapestry等等）的验证总归是不能解决业务深层次的验证，我认为也不能让业务的深层次验证提到展现层来验证，那样违背了MVC的本意。
实际上，验证的规则是有章可循的，无非最大，最小，不能为空。。。。。。等等，所以其重用也是可能的。Vlad框架做到了。
验证又怎样从逻辑中剥离呢？ 这其中实际上就涉及到AOP（面向方面编程）技术了，作为java程序员，java似乎目前AOP特征一般，我们就不能做了？ 不，还是可以做到的。nanning是一个非常优秀的基于Java的AOP框架。
那么，结合两者，我们的验证代码和业务逻辑是分开的，前者不污染后者，使得code smell good，验证又可以重用的情况使得我们的code smell very good.
我已经在一个期货系统中作了具体的应用---纯净的代码。
详情请到http://www.erproad.org上参阅，我将在未来的日子给出一个较好的解决方案。
------------------------------------------------------
nanning是一个非常简单甚至有些低能的AOP框架
验证一般和每个具体商业逻辑相关,多数情况都不属于cross-cutting问题,你写太多的intercepter是很难维护调试的
如果是仅仅展现层验证
Tapestry并非如你所说的类似于taglib般的解决方法，可以这么说，不和taglib搭边，tapestry是组件方式编程，既然称其为组件，自然其可重用性要强调。我建议你去看看几个组件ValidField，DateField NumericField，或许对你有所帮助。
当然，结合Vlad就更加好了。下午我就在做这个。
你说的nanning简单,我认为是的，我就是要他的简单性。 在一般性的面向对象编程中，谁也别指望我去学习和应用复杂费劲的其他AOP框架或者语言。
至于低效，呵呵，我想应用实例说明了一切，一年前我就在项目中应用nanning，系统现在在运行，没有什么特别的放映。 我在系统的核心状态转移中的状态验证以及权限验证都是采用nanning，但是好像还是0.9(?)版本吧，很不错的。
另外，如果是代码增强型以及class增强型的AOP我也拒绝，nanning不一样，运行时增强。
PS: 或许你能有更好的AOP框架，不妨共享之.......
至于是否是cross-cutting的问题，我同意。
当然，既然是商业逻辑相关的，涉及的是状态相关或者其他的，这些都不在于bean验证的范围，也不是一个bean能解决的问题，这时候，或许就不是验证了，而是逻辑了。
至于说incepter，我想好的代码结构以及好的命名规范，不至于产生什么太大的问题。
我觉得，倒是粒度需要考虑。
hehe,其实我没说准确,应该是每个业务方法需要验证的东西大部分都不一样,bean验证是可以做到的,当然也不是优雅的完成的,比如struts1.0
是在每个formbean中都一个验证方法,1.1不过是搬到配置文件了
当然你也可以给个配置文件或者其他什么的,告诉intercepter/advice目标方法需要验证的内容,相当于自己一个重新实现一个验证框架
intercepter太多非常麻烦,很难维护,特别是对非cross-cutting的问题到处使用就算是滥用了,也没达到相应的AOP的初衷,成了为AOP而AOP,还不如直接用OO.单单从维护性的角度,我决得最好的一种方法是用runtime attribute指定pointcut,XML其次,它集中提供了所有的信息,如果XML转化一下成为更可读的格式可能更方便,aspectj在语言中可能最差