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之類的(這個我測試過，確實可以);或者做一些只有保存時才需要的驗證（這個沒有測試過，理論上應該可以，後面有空的話會測試一下）.
