EBS OAF开发中的Java 实体对象(Entity Object)验证功能补充

EBS OAF开发中的Java 实体对象(Entity Object)验证功能补充

（版权声明，本人原创或者翻译的文章如需转载，如转载用于个人学习，请注明出处；否则请与本人联系，违者必究）

EO理论上是仅仅有产品组维护，里面包括其全部的业务逻辑，并提供对应的Expert给自己或者其他产品组使用。而VO是各个组依据须要或基于EO或者仅仅读的SQL而建立的，里面能够依据须要加入自己的业务实现和逻辑。

对于EO内部的验证功能，在开发文档中主要介绍了三种：

1. 在setter里面实现单个属性的验证。这主要是对于没有依赖关系的属性，也就是说它的验证不须要其他会被改动的属性的支持。比方，验证一个数量是不是正数，是不是在一个范围之内；可是假设其也要依赖界面上的输入的计量单位的话，就要考虑row层次上的验证，由于setter的调用顺序是未知的，可能先调用数量的setter，然后再调用计量单位的setter，这样的验证就会有问题了。

2. 在Row层次上进行跨属性的验证.由于在全部须要调用的setter都调用完之后，会调用row层次的验证方法validateEntity().全部行级的跨属性验证都应该放在这里。它的缺点是，每次request中假设有调用setter的话，就会调用row层次的校验，所以在开发文档中有这么一句话，

Any logic which operates at the row level -- and is not particularly sensitive to being called repeatedly --should be included in the validateEntity() method.

也就是说全部行级的且对反复调用不敏感的验证能够放在这里，怎样定义敏感，我的理解是1.每次验证花费的时间非常多；2.一个transaction里多次请求每次都会调用setter，比方大量的PPR事件，会导致多次验证，可能影响用户体验;可是开发文档中尽管这么说了，但并没有说明这样的不能反复调用的验证应该在哪里实现，怎样实现。

3. 进行跨实体属性验证.对于composition的AO来说，这个不是问题，由于detail的验证总是发生在master的验证之前；而对于reference的来说，就要实现相似“调解人”的对象，其须要实现ValidationListener接口。但这样的情况较少，并且适用范围较小。

对于另外一种情况的例外，能够考虑覆盖基类OAEntityImpl的prepareForDML()方法.对于其，Javadoc有以下的说明

Process a row when any operation like insert/update/deleteis performed. User can overwrite this method and add any custom logic, likeinitialize any attribute on insertion.

也就是在构建DML SQL语句之前，我们能够对这个row做一些处理，比方设置一些属性且其仅仅有在保存的时候才须要设置的，如获取sequence之类的(这个我測试过，确实能够);或者做一些仅仅有保存时才须要的验证（这个没有測试过，理论上应该能够，后面有空的话会測试一下）.