[英]Understanding the Spring Data JPA @NoRepositoryBean interface
在閱讀 Spring Data 文檔時,我多次遇到@NoRepositoryBean
接口。
引用文檔:
如果您正在使用 Spring 命名空間使用自動存儲庫接口檢測,那么按原樣使用接口將導致 Spring 嘗試創建 MyRepository 的實例。 這當然不是我們想要的,因為它只是充當 Repository 和您要為每個實體定義的實際存儲庫接口之間的中介。 要排除擴展 Repository 的接口被實例化為存儲庫實例,請使用
@NoRepositoryBean
對其進行注釋。
但是,我仍然不確定何時何地使用它。 有人可以建議並給我一個具體的用法示例嗎?
該注釋用於避免為實際上符合回購接口標准但不打算成為一個接口的接口創建存儲庫代理。 只有在您開始使用功能擴展所有存儲庫時才需要它。 讓我舉一個例子:
假設您想要將方法 foo() 添加到所有存儲庫。 您將從添加這樣的回購界面開始
public interface com.foobar.MyBaseInterface<…,…> extends CrudRepository<…,…> {
void foo();
}
您還可以添加相應的實現類、工廠等。 您的具體存儲庫接口現在將擴展該中間接口:
public interface com.foobar.CustomerRepository extends MyBaseInterface<Customer, Long> {
}
現在假設您引導程序——比方說 Spring Data JPA——如下所示:
<jpa:repositories base-package="com.foobar" />
您使用com.foobar
是因為您在同一個包中有CustomerRepository
。 Spring Data 基礎架構現在無法判斷MyBaseRepository
不是具體的存儲庫接口,而是充當中間存儲庫來公開附加方法。 所以它會嘗試為它創建一個存儲庫代理實例並失敗。 您現在可以使用@NoRepositoryBean
來注釋這個中間接口,從本質上告訴 Spring Data:不要為此接口創建存儲庫代理 bean。
這種情況也是CrudRepository
和PagingAndSortingRepository
帶有此注釋的原因。 如果包掃描意外拾取了那些(因為您不小心以這種方式配置了它),引導程序將失敗。
長話短說:使用注解來防止存儲庫接口被選為最終成為存儲庫 bean 實例的候選對象。
我們可以聲明一個新接口作為我們的自定義方法:
@NoRepositoryBean
public interface ExtendedRepository<T, ID extends Serializable> extends JpaRepository<T, ID> {
List<T> findByAttributeContainsText(String attributeName, String text);
}
我們的接口擴展了 JpaRepository 接口,因此我們將從所有標准行為中受益。
您還會注意到我們添加了 @NoRepositoryBean 注釋。 這是必要的,否則默認的 Spring 行為是為 Repository 的所有子接口創建一個實現。
public interface ExtendedStudentRepository extends ExtendedRepository<Student, Long> {
}
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.