3 回答

TA貢獻(xiàn)2041條經(jīng)驗(yàn) 獲得超4個(gè)贊
Ken的回答基本上是正確的,但我想提一下“您為什么要在另一個(gè)上使用一個(gè)?” 您的問題的一部分。
基本
您為存儲(chǔ)庫(kù)選擇的基本接口有兩個(gè)主要目的。首先,您允許Spring Data存儲(chǔ)庫(kù)基礎(chǔ)結(jié)構(gòu)找到您的接口并觸發(fā)代理創(chuàng)建,以便將接口實(shí)例注入客戶端。第二個(gè)目的是在接口中引入所需的功能,而不必聲明其他方法。
通用接口
Spring Data核心庫(kù)附帶兩個(gè)基本接口,它們公開了一組專用功能:
CrudRepository -CRUD方法
PagingAndSortingRepository-分頁和排序方法(擴(kuò)展CrudRepository)
商店特定的界面
各個(gè)商店模塊(例如,針對(duì)JPA或MongoDB的商店模塊)公開了這些基本接口的特定于商店的擴(kuò)展,以允許訪問特定于商店的功能(例如沖洗或?qū)S门幚恚@些功能考慮了一些特定于商店的情況。這方面deleteInBatch(…)的一個(gè)示例與之JpaRepository不同,delete(…)因?yàn)樗褂貌樵儊韯h除給定的實(shí)體,該實(shí)體的性能更高,但具有不觸發(fā)JPA定義的級(jí)聯(lián)(如規(guī)范定義)的副作用。
我們通常建議不要使用這些基本接口,因?yàn)樗鼈儠?huì)將底層的持久性技術(shù)公開給客戶端,從而加強(qiáng)了它們與存儲(chǔ)庫(kù)之間的耦合。另外,您與存儲(chǔ)庫(kù)的原始定義有所不同,該存儲(chǔ)庫(kù)基本上是“實(shí)體集合”。因此,如果可以,請(qǐng)繼續(xù)PagingAndSortingRepository。
自定義存儲(chǔ)庫(kù)基礎(chǔ)接口
直接取決于所提供的基本接口之一的缺點(diǎn)是雙重的。他們都可以被認(rèn)為是理論上的,但是我認(rèn)為重要的是要意識(shí)到:
取決于Spring Data存儲(chǔ)庫(kù)接口,可將您的存儲(chǔ)庫(kù)接口耦合到庫(kù)。我認(rèn)為這不是一個(gè)特別的問題,因?yàn)槟赡苋詴?huì)在代碼中使用Page或之類的抽象Pageable。Spring Data與其他通用庫(kù)(如commons-lang或Guava)沒有任何不同。只要提供合理的利益,就可以了。
通過擴(kuò)展eg CrudRepository,您可以一次公開一套完整的持久性方法。在大多數(shù)情況下,這也可能很好,但是您可能會(huì)遇到想要對(duì)暴露的方法獲得更細(xì)粒度控制的情況,例如,創(chuàng)建ReadOnlyRepository不包含save(…)和delete(…)方法的CrudRepository。
解決這兩個(gè)缺點(diǎn)的方法是設(shè)計(jì)您自己的基本存儲(chǔ)庫(kù)接口,甚至是其中的一組。在許多應(yīng)用程序中,我看到了類似以下內(nèi)容:
interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }
interface ReadOnlyRepository<T> extends Repository<T, Long> {
// Al finder methods go here
}
第一個(gè)存儲(chǔ)庫(kù)接口是一些通用的基礎(chǔ)接口,它實(shí)際上僅修復(fù)點(diǎn)1,而且將ID類型綁定Long為保持一致性。第二個(gè)接口通常具有find…(…)從中復(fù)制的所有方法CrudRepository,PagingAndSortingRepository但沒有公開操作方法。在參考文檔中閱讀有關(guān)該方法的更多信息。
存儲(chǔ)庫(kù)抽象使您可以選擇完全由架構(gòu)和功能需求驅(qū)動(dòng)的基礎(chǔ)存儲(chǔ)庫(kù)。如果適合,請(qǐng)使用開箱即用的提供的接口,并在必要時(shí)制作自己的存儲(chǔ)庫(kù)基礎(chǔ)接口。除非不可避免,否則請(qǐng)遠(yuǎn)離商店特定的存儲(chǔ)庫(kù)接口。
添加回答
舉報(bào)