我正在編寫一個包含域模型並使用Bean驗證API的庫。我的目標是擁有最小量的依賴關係。因此，沒有CDI，Java EE和Spring。允許依賴關係僅適用於API，如JSR-349和JSR-330 API。使用庫中的JSR-303/JSR-349進行方法驗證
我無法對我的庫如何使用做任何假設。它可能在一個容器內或作爲桌面應用程序。強制庫用戶擁有CDI，Spring或驗證實現不是一種選擇。
現在，我使用bean驗證API來允許我的庫的用戶驗證模型本身。但是我也想在某些情況下使用方法驗證。
我的問題是：
我有什麼選擇，如果我想使用 庫項目中的方法驗證？
我必須運送我的庫與一個aspectj運行時依賴？
在域模型中使用方法驗證有意義嗎？
您的圖書館將如何使用？無論如何，使用它的應用程序可能在CDI，Spring或其他類型的容器中運行，然後將方法驗證委託給它們將是明智的。
如果你真的想爲自己的解決方案，它真的取決於如何創建您的域模型的實例。如果您有接口並且用戶通過工廠獲取實例，則可以查看JDK動態代理。或者，如果您不使用接口但使用類，則可以檢出Javassist或Cglib。這仍然需要您的域模型節點通過工廠獲得，以便正確返回代理實例。
是否有意義或不確定取決於您的具體型號及其使用案例。當涉及到對模型的驗證時，屬性（和類級別）驗證肯定是更常見的情況，但是如果您在模型上提供業務方法並想驗證其參數或返回值，則可能有意義。
1）沒有CDI我會推薦apache BVal或任何不需要被容器管理的jsr303特定實現。
由於jsr以java-ee平臺爲目標，因此似乎有些容器必須管理它。您選擇的容器取決於必須隨應用程序一起提供的額外依賴項。
Bval本身不需要任何其他一些核心apache幫助程序庫。
2）jsr303規範的Bval和其他實現將需要某種java ee容器。它是java ee背後的支持原則。如果沒有java-ee環境，則bval將需要一個di框架來掛鉤。
如果選擇guice作爲容器;它使用cglib作爲字節碼，並且它的aop使用aop聯盟接口（在cglib的幫助下內部實現）。
Spring確實需要aspectj。
如果選擇CDI，則取決於所使用的CDI實施。 3）如果您試圖簡單地進行方法級別驗證，那麼僅僅在類設置器/ getter本身中手動進行驗證確實有意義。特別是如果你想保持平臺獨立。
通過使用第三方庫進行方法級別驗證只有在使用第三方容器時纔有意義。如果您試圖建立一個簡單的基於Java的應用程序，那麼將驗證放入數據對象本身並且讓您的異常處理策略將問題處理給用戶是非常有意義的。
對三者的回答總是相當主觀，但如果你確實不想使用大量的框架，我不認爲它在方法本身中進行驗證的不良做法。
如果你不想使用重量級容器...你可以使用pico容器或者guice。 Guice有303個鉤子，但我不認爲它提供了303實現（儘管我不太確定，我喜歡手動驗證） – AnthonyJClink
庫不應該隨容器一起發貨，這將使它幾乎不可能集成到現有的應用程序中。 – Vadimo
我想你誤解了我在這裏的容器定義......即時通訊談論一個IOC容器，一個簡單的庫。不是實際運行的jvm實現。使用guice/spring/pico容器仍然可以確保你不受限於任何特定的jvm實現@Vadimo – AnthonyJClink