如何將複雜的業務驗證與JSR-303合併？

我在我當前的用例中進行了驗證。我的應用程序具有標準結構（WEB < - > EJB3服務< - > EJB3 DAO < - > DB）。我有一個應用了驗證註釋的實體。如何將複雜的業務驗證與JSR-303合併？

@Entity 
class PhoneNumber { 

    ... 

    private NumberType numberType; 
}

其中

enum NumberType { 
    FIXED, 
    MOBILE, 
    ANY 
}

現在我有新的驗證規則應用。在PhoneNumber更新中，如果之前設置爲FIXED或MOBILE，則不應將NumberType更改爲ANY。只是數據庫操作之前

我Bean驗證規則進行檢查，並且上面的規則應該在業務層應用（至少我是這麼認爲的），有一個DB訪問取得了先前的實體版本進行比較。但沒有bean尚未驗證，我不得不手動檢查，例如， numberType不爲null。

能否請您使用Bean驗證時提供給我一些建議或一般規則如何應對更復雜的業務內容驗證（不僅是在隔離檢查單字段的值）？

2011-07-15 grafthez

Here你可以找到如何編寫自定義驗證它可以做「交叉領域」驗證一個很好的說明。

2011-07-15 07:31:11 Kai

謝謝，但這不符合我的問題。我不需要跨場驗證。我需要驗證一個字段與之前的值（存儲在數據庫中）。 – grafthez

因此，您必須從自定義驗證程序中的數據庫中查詢實體，並檢查其值。但我認爲這不是一個好習慣。相反，我會加載業務邏輯中的舊實體，並在這裏檢查它的值。這樣你就不會將這個邏輯隱藏在驗證器中。 – Kai

我不認爲Bean驗證是實現這種業務邏輯的解決方案。

相反，你可以實現這個檢查在PhoneNumber實體的setNumberType()方法。在那裏你有舊的價值，並且與服務層中的實現相比，通過規避（意外或有意）執行檢查的服務，沒有機會執行非法狀態轉換。

2011-07-15 18:55:29 Gunnar

我同意你的第一段。但我不會把支票放入實體。在我看來，實體類只是POJO，不應該包含商業邏輯。否則，你無法推動業務邏輯，因爲在任何設置器中都可能做出一些隱含的更改。這也使重構變得困難，並且如果邏輯如此分散，很難監督用例。 – Kai

回答