領先一步
VMware 提供培訓和認證，以加速您的進度。
了解更多Spring Data Lovelace 的新功能
Spring Data Lovelace 上週已發布正式版本，現在是時候簡要了解我們新增的功能了。此版本包含非常多的功能。在這篇部落格文章中，我將介紹更通用的功能。進階的、特定於儲存的新聞將在以下部落格文章中介紹：
讀完了嗎？ 好的，讓我們開始介紹更通用的項目。
針對不可變類型的改進物件映射
在 Spring Data Lovelace 中，我們有機會改造大多數 NoSQL 模組使用的物件映射工具。 我們一直支援不可變實體，但有一個小地方除外：在資料庫互動期間需要變更的值（例如自動產生的識別碼或樂觀鎖定版本屬性）始終在底層變更。 在最新版本中，這種情況已發生變化。
為了支援這些屬性，我們現在需要您提供 wither 方法（遵循 with…(…) 命名慣例）或 - 在 Kotlin 世界中 - 公開專用的 copy(…) 方法，將所有屬性作為引數。 以下範例使用 withId 方法
class Person {
private final Long id;
private final String firstname, lastname;
static Person of(String firstname, String lastname) {
return new Person(null, firstname, lastname);
}
private Person(Long id, String firstname, String lastname) {
// Assign parameters to fields
}
Person withId(Long id) {
return new Person(id, this.firstname, this.lastame);
}
// …
}
使用 Lombok，我們可以執行相同的操作，如下所示
@Value(staticConstructor = "of")
class Person {
@Wither Long id;
String firstname, lastname;
// …
}
當從資料庫讀取 Person 實例時，會使用宣告的建構函式。 當首先將新實體保存到儲存區時，識別碼屬性的 wither 方法會發揮作用。 請務必實際使用從儲存庫的 save(…) 方法傳回的結果，因為這現在將與您首先傳遞給該方法的實例不同。
我們使用了該方面的工作，透過避免在使用不可變類型時對屬性進行幾次不必要的迭代，來提高某些儲存實作中實際物件轉換的效能。 有關更多詳細資訊，請參閱新新增的 參考文件區段。
支援 Vavr 的 Try Monad
預設情況下，Spring Data 儲存庫會將查詢方法執行期間發生的錯誤作為執行階段例外狀況傳播。 編寫 Java 程式碼的更函式風格的支持者通常在其應用程式中使用 Vavr。 我們已經支援 Vavr 的集合類型作為儲存庫傳回類型很長一段時間了。 Spring Data Lovelace 現在新增了對 Try monad 的支援，以便查詢方法執行中發生的錯誤會導致傳回 Failure 實例，而不是擲回例外狀況。
interface PersonRepository extends Repository<Person, Long> {
Try<Option<Person>> findByLastnameContaining(String lastname);
}
如果找到多個 lastname 符合給定條件的人員，則該方法會失敗。 使用 Try 作為傳回類型，用戶端元件現在可以從該異常情況中恢復，如下所示
repository.findByLastnameContaining("e")
.recover(it -> Match(it).of(
Case(instanceOf(IncorrectResultSizeDataAccessException.class), Optional.empty())
));
雖然這在這個虛構的小範例中看起來有點複雜，但它是一種非常強大的機制，可以繼續對可能拋出例外狀況的程式碼中的潛在可用結果進行映射。 請注意，將交易儲存區與此功能結合使用時，您必須自行管理交易回復，因為實際上不再擲回例外狀況，並且不會觸發針對 @Transaction 註釋方法的交易回復。 對此的支援正在進行中。 請務必關注 Spring Framework 中的 此票證，甚至對其投下一票。
若要查看 Vavr 支援的實際運作情況，請查看我們的標準 Spring Data 範例儲存庫中的 範例。
延遲的 JPA 儲存庫初始化
啟動 Spring Data JPA 應用程式需要啟動 EntityManagerFactory。 這通常會消耗應用程式總啟動時間的相當一部分。 為了解決此問題，Spring Framework 已經引入了在背景執行緒中啟動 EntityManagerFactory 的能力，因此，讓其他 bean 並行初始化。 遺憾的是，Spring Data 儲存庫通常至少對某種類型的 Spring bean 具有一個可傳遞的相依性。 反過來，它們的初始化會與工廠互動，這 - 如果沒有進一步的步驟 - 會導致其他元件的初始化被阻止。 這大大限制了該新功能的影響。
從 Spring Data Lovelace 開始，您現在可以定義以延遲模式啟動的儲存庫，這會自動將 Spring Data 儲存庫的所有注入點宣告為延遲。 這會導致 Spring Framework 建立 Proxy 並延遲實際的儲存庫初始化，直到與它們的第一次互動為止。 換句話說，儲存庫用戶端和這些用戶端的用戶端可以反過來建立，而無需等待 EntityManagerFactory 完成其啟動。 這表示可以將顯著更多的 Spring bean 初始化與 JPA 啟動並行化。
初始化的延遲也會導致任何類型的驗證被延遲，直到（例如）實際使用儲存庫的程式碼路徑的第一次請求。 如果您仍然想確保儲存庫在應用程式開始接收請求之前已完全初始化，請使用延遲啟動模式。 此模式的工作方式與延遲模式相同，只是當容器完成啟動時，它會明確觸發 ApplicationContext 中所有儲存庫的初始化。
在這些模式之間切換的最簡單方法是將 Spring Boot 屬性 spring.jpa.repositories.bootstrap-mode 設定為 lazy 或 deferred。 這也確保已正確設定 EntityManagerFactory 的延遲初始化。 此外，請務必查看新增到 參考文件的新區段。
範例
我們準備了 一個範例，以展示在一個相當極端的範例中，由 2,000 個實體、2,000 個儲存庫和 2,000 個依賴於儲存庫的 bean 組成，該最佳化的效果。 使用延遲模式可減少約三分之一（~12 秒）的啟動時間。 延遲模式甚至可以減少另外三分之一（比預設值快約 22 秒）。
控制 Spring Data REST 中的 HTTP 方法公開
最後，我們來看一個 Spring Data REST 中的功能，該功能已被請求了一段時間。 在 Spring Data REST 中，關於哪些 HTTP 方法支援哪些公開的資源類型的決策預設是由宣告的 CRUD 方法驅動的。 但是，在某些情況下，單個儲存庫方法的存在會導致啟用多個資源-HTTP 方法組合。 例如，在儲存庫上公開的 save(…) 方法會導致在集合資源上支援 POST，以及用於更新和建立項目資源的 PUT。
Spring Data Lovelace 有一個新的 ExposureConfiguration（可從 RepositoryRestConfiguration 取得），它允許細粒度地控制應公開哪些方法
ExposureConfiguration config = restConfiguration.getExposureConfiguration();
config.withItemExposure((metadata, httpMethods)
-> httpMethods.disable(HttpMethod.PATCH));
config.forDomainType(User.class).disablePutForCreation();
如您所見，配置選項有兩種形式
-
一個全域的（首先顯示），允許透過
ResourceMapping和ConfigurableHttpMethods上的 Lambda 來控制集合、項目和關聯資源的公開。 -
一個特定類型的，如下所示。某些設定細節，例如禁用（預設啟用）使用
PUT請求建立實體的功能，可以使用明確的配置方法來支援。
您可以在參考文檔的相應章節中找到更多相關資訊。