投射
Spring Data 查詢方法通常會回傳儲存庫所管理的聚合根的一個或多個實例。然而,有時可能需要根據這些類型的特定屬性建立投射。Spring Data 允許建立專用的回傳類型模型,以更有選擇性地檢索受管理聚合的部分視圖。
想像一個儲存庫和聚合根類型,如下列範例所示
class Person {
@Id UUID id;
String firstname, lastname;
Address address;
static class Address {
String zipCode, city, street;
}
}
interface PersonRepository extends Repository<Person, UUID> {
Collection<Person> findByLastname(String lastname);
}
現在想像一下,我們只想檢索人員的姓名屬性。Spring Data 提供哪些方法來達成此目的?本章的其餘部分將回答這個問題。
投射類型是位於實體類型階層之外的類型。實體實作的超類別和介面位於類型階層之內,因此回傳超類型(或實作的介面)會回傳完全具體化實體的實例。 |
基於介面的投射
將查詢結果限制為僅姓名屬性的最簡單方法,是宣告一個介面,該介面公開要讀取的屬性的存取器方法,如下列範例所示
interface NamesOnly {
String getFirstname();
String getLastname();
}
這裡的重點是,此處定義的屬性與聚合根中的屬性完全匹配。這樣做可以新增查詢方法,如下所示
interface PersonRepository extends Repository<Person, UUID> {
Collection<NamesOnly> findByLastname(String lastname);
}
查詢執行引擎會在執行階段為每個回傳的元素建立該介面的代理實例,並將對公開方法的呼叫轉發到目標物件。
在您的 Repository 中宣告覆寫基礎方法(例如,在 CrudRepository 、特定商店的儲存庫介面或 Simple…Repository 中宣告)的方法,將導致呼叫基礎方法,而與宣告的回傳類型無關。請確保使用相容的回傳類型,因為基礎方法不能用於投射。某些商店模組支援 @Query 註解,以將覆寫的基礎方法轉換為查詢方法,然後可用於回傳投射。 |
投射可以遞迴使用。如果您也想包含一些 Address
資訊,請為其建立一個投射介面,並從 getAddress()
的宣告中回傳該介面,如下列範例所示
interface PersonSummary {
String getFirstname();
String getLastname();
AddressSummary getAddress();
interface AddressSummary {
String getCity();
}
}
在方法調用時,會取得目標實例的 address
屬性,並依序包裝到投射代理中。
封閉式投射
存取器方法全部與目標聚合的屬性匹配的投射介面被視為封閉式投射。以下範例(我們在本章稍早也使用過)是一個封閉式投射
interface NamesOnly {
String getFirstname();
String getLastname();
}
如果您使用封閉式投射,Spring Data 可以最佳化查詢執行,因為我們知道支援投射代理所需的所有屬性。有關更多詳細資訊,請參閱參考文件中的模組特定部分。
開放式投射
投射介面中的存取器方法也可以使用 @Value
註解來計算新值,如下列範例所示
interface NamesOnly {
@Value("#{target.firstname + ' ' + target.lastname}")
String getFullName();
…
}
支援投射的聚合根可在 target
變數中使用。使用 @Value
的投射介面是開放式投射。在這種情況下,Spring Data 無法應用查詢執行最佳化,因為 SpEL 表達式可以使用聚合根的任何屬性。
@Value
中使用的表達式不應太複雜 — 您應該避免在 String
變數中編寫程式。對於非常簡單的表達式,一種選擇可能是使用預設方法(在 Java 8 中引入),如下列範例所示
interface NamesOnly {
String getFirstname();
String getLastname();
default String getFullName() {
return getFirstname().concat(" ").concat(getLastname());
}
}
此方法要求您能夠完全根據投射介面上公開的其他存取器方法來實作邏輯。第二種更靈活的選擇是在 Spring Bean 中實作自訂邏輯,然後從 SpEL 表達式中調用該邏輯,如下列範例所示
@Component
class MyBean {
String getFullName(Person person) {
…
}
}
interface NamesOnly {
@Value("#{@myBean.getFullName(target)}")
String getFullName();
…
}
請注意 SpEL 表達式如何參照 myBean
並調用 getFullName(…)
方法,並將投射目標作為方法參數轉發。由 SpEL 表達式評估支援的方法也可以使用方法參數,然後可以從表達式中參照這些參數。方法參數可透過名為 args
的 Object
陣列取得。以下範例顯示如何從 args
陣列取得方法參數
interface NamesOnly {
@Value("#{args[0] + ' ' + target.firstname + '!'}")
String getSalutation(String prefix);
}
同樣地,對於更複雜的表達式,您應該使用 Spring Bean,並讓表達式調用方法,如稍早所述。
可為 Null 的包裝器
投射介面中的 Getter 可以使用可為 Null 的包裝器來改善 Null 安全性。目前支援的包裝器類型包括
-
java.util.Optional
-
com.google.common.base.Optional
-
scala.Option
-
io.vavr.control.Option
interface NamesOnly {
Optional<String> getFirstname();
}
如果底層投射值不是 null
,則會使用包裝器類型的 present 表示法回傳值。如果後端值為 null
,則 Getter 方法會回傳所用包裝器類型的空表示法。
基於類別的投射 (DTO)
定義投射的另一種方法是使用值類型 DTO(資料傳輸物件),這些 DTO 保留要檢索的欄位的屬性。這些 DTO 類型可以與投射介面完全相同的方式使用,只是不會發生代理,並且無法應用巢狀投射。
如果商店透過限制要載入的欄位來最佳化查詢執行,則要載入的欄位會從公開的建構子的參數名稱中判斷。
以下範例顯示投射 DTO
record NamesOnly(String firstname, String lastname) {
}
Java Records 是定義 DTO 類型的理想選擇,因為它們遵循值語意:所有欄位都是 private final
,並且會自動建立 equals(…)
/hashCode()
/toString()
方法。或者,您可以使用任何定義您想要投射的屬性的類別。
動態投射
到目前為止,我們已將投射類型用作集合的回傳類型或元素類型。但是,您可能想要在調用時選取要使用的類型(這使其成為動態類型)。若要應用動態投射,請使用查詢方法,如下列範例所示
interface PersonRepository extends Repository<Person, UUID> {
<T> Collection<T> findByLastname(String lastname, Class<T> type);
}
這樣,該方法可用於取得聚合本身,或套用投射的聚合,如下列範例所示
void someMethod(PersonRepository people) {
Collection<Person> aggregates =
people.findByLastname("Matthews", Person.class);
Collection<NamesOnly> aggregates =
people.findByLastname("Matthews", NamesOnly.class);
}
會檢查 Class 類型的查詢參數是否符合動態投射參數的資格。如果查詢的實際回傳類型等於 Class 參數的泛型參數類型,則符合的 Class 參數無法在查詢或 SpEL 表達式中使用。如果您想要將 Class 參數用作查詢引數,請確保使用不同的泛型參數,例如 Class<?> 。 |