验证实在也是个比较麻烦的事，验证能否重用？验证是否能与业务分开？怎样使得业务逻辑不被一些琐碎的验证肢解成了ugly code？ 在展现层（如，Struts,tapestry等等）的验证总归是不能解决业务深层次的验证，我认为也不能让业务的深层次验证提到展现层来验证，那样违背了MVC的本意。
实际上，验证的规则是有章可循的，无非最大，最小，不能为空。。。。。。等等，所以其重用也是可能的。Vlad框架做到了。
验证又怎样从逻辑中剥离呢？ 这其中实际上就涉及到AOP（面向方面编程）技术了，作为java程序员，java似乎目前AOP特征一般，我们就不能做了？ 不，还是可以做到的。nanning是一个非常优秀的基于Java的AOP框架。
那么，结合两者，我们的验证代码和业务逻辑是分开的，前者不污染后者，使得code smell good，验证又可以重用的情况使得我们的code smell very good.
我已经在一个期货系统中作了具体的应用---纯净的代码。
详情请到http://www.erproad.org上参阅，我将在未来的日子给出一个较好的解决方案。
