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