在JAVA中这从来不是什么大问题，特别是主流ORM组件如Hibernate的使用，加Struts的validator，不太严格的服务器端验证就差不多O了。

在PHP中，我们一样也面临这个问题，ORM当然也不再是问题，目前有些CMS中也已可见轻量级的model自动生成（根据数据表），生成无外键的单表对象模型，另一些知名的开源ORM当然已经和Hibernate一样实现了复杂的ORM。

我们这儿先说数据格式验证。

 

kolidon倒是见过其他公司自有的商业框架中的复杂的验证模型，他们试图以java开发者的视角观察一切，巧合的是，这帮家伙几年前就在 joomla1.0上实现了自已的1.5…:-)。不管怎样，这样的框架已基本堪用了，甚至，有时能感觉到，只要这帮家伙再努把力，甚至能自动生成前端js验证代码。

但实际使用时，仍然面临太多问题，如代码复杂度倍数级增长，代码量狂增导致的性能损失。若一个代码框架语法和逻辑过于复杂，这些后果似乎是必然的。

难于分解的复杂系统最终将被抛弃，因为维护成本、学习成本还有，随着应用的市场系统，构建相对简单的系统是如此方便，而将相对简单的系统组合后，仍然会有无限的可能。

 

一个事实“我们接触的绝大多数项目，都是需求变化极大的网站平台，离“WEB应用”这个词其实仍然有那么些距离。也就是说，无论在价值及使用方式上，对数据验证一致性的要求非常低。另外，虽然我们一直在努力，但事情似乎永远没完没了。

典型的例子是wordpress个人博客的反垃圾评论的战争。见这儿、这儿、还有这儿。

道高一尺、魔高一丈。如果无法可想，那就换一种思路。

 

考虑一下，只要安全性能过关，那么一个电话号码位数多或者少个一两位，恐怕并没有太严重的后果，因为，我们不可能知道用户填了个虚构的电话号码或者邮件地址——能连到银行去验证信用卡真伪的除外，那个当然也不保险，最万无一失的的是扣掉你一块钱，然后再打给你——这就是我们在当今体验到的极端验证法。

若一个varchar字段超长，mysql数据更可能是自动截断，而整型数据超出范围，能遇上的用户也基本上不可能是合法用户——这种可能性我们在这么多网站项目中基本上就没怎么遇上过。能手工制作URL传入自定义值的非法用户，若还能识别传统的验证码，最终实现了批量向站点中写入数据，只要数据是需要验证才能显示的，那么这些动作能产生的价值就几乎为零（kolidon博客后台中的数万条垃圾评论为证）。

不要害怕垃圾评论，只需要让垃圾永远没有机会露头污染到大家。不完美并不是什么难堪的事情。

 

我们将注意力更多转到了前台。几年前，我们试用了一些集成式解决方案，更多的是自己写JS。而jquery大行其道后，我们使用Tootip和Validation，事情正变得越来越简单。

 

同时，我们也在寻找PHP的ORM组件，当前google给出的结论是Doctrine and Propel，满心期待这些组件除了提供基本的OR映射外，还能有后端验证功能，若还能在前端验证上做一些工作就更完美了。

不过，若能有后端验证，从此出发，生成供Validation插件使用的js代码仅一步之遥。