通用 ORM 整合考量
本節重點介紹適用於所有 ORM 技術的考量。 Hibernate 區段提供更多詳細資訊,並在具體情境中展示這些功能和組態。
Spring 的 ORM 整合的主要目標是清晰的應用程式分層(使用任何資料存取和交易技術)以及應用程式物件的鬆散耦合 — 業務服務不再依賴資料存取或交易策略,不再有硬編碼的資源查閱,不再有難以更換的 Singleton,不再有自訂服務註冊表。目標是擁有一種簡單且一致的方法來連接應用程式物件,使其盡可能可重複使用且不受容器依賴性的影響。所有個別的資料存取功能都可以單獨使用,但與 Spring 的應用程式 Context 概念完美整合,提供基於 XML 的組態以及對不需要感知 Spring 的純 JavaBean 實例的交叉引用。在典型的 Spring 應用程式中,許多重要的物件都是 JavaBean:資料存取範本、資料存取物件、交易管理員、使用資料存取物件和交易管理員的業務服務、Web 檢視解析器、使用業務服務的 Web 控制器等等。
資源和交易管理
典型的業務應用程式充斥著重複的資源管理程式碼。許多專案嘗試發明自己的解決方案,有時為了程式設計的便利性而犧牲了對失敗的適當處理。Spring 提倡針對適當的資源處理採用簡單的解決方案,即在 JDBC 的情況下透過範本化進行 IoC,並為 ORM 技術應用 AOP 攔截器。
基礎架構提供適當的資源處理,並將特定的 API 例外狀況適當地轉換為未檢查的基礎架構例外狀況階層。Spring 引入了 DAO 例外狀況階層,適用於任何資料存取策略。對於直接 JDBC,前一節中提到的 JdbcTemplate
類別提供連線處理,並將 SQLException
適當地轉換為 DataAccessException
階層,包括將資料庫特定的 SQL 錯誤代碼翻譯為有意義的例外狀況類別。對於 ORM 技術,請參閱下一節,以了解如何獲得相同的例外狀況翻譯優勢。
在交易管理方面,JdbcTemplate
類別掛鉤到 Spring 交易支援,並透過各自的 Spring 交易管理員支援 JTA 和 JDBC 交易。對於受支援的 ORM 技術,Spring 透過 Hibernate 和 JPA 交易管理員以及 JTA 支援提供 Hibernate 和 JPA 支援。有關交易支援的詳細資訊,請參閱交易管理章節。
例外狀況翻譯
當您在 DAO 中使用 Hibernate 或 JPA 時,您必須決定如何處理持久化技術的原生例外狀況類別。DAO 拋出 HibernateException
或 PersistenceException
的子類別,具體取決於技術。這些例外狀況都是 RuntimeException,不必宣告或捕獲。您可能還需要處理 IllegalArgumentException
和 IllegalStateException
。這表示呼叫者只能將例外狀況視為一般致命錯誤來處理,除非他們想要依賴持久化技術自身的例外狀況結構。如果不將呼叫者與實作策略綁定,就無法捕獲特定原因(例如樂觀鎖定失敗)。對於強烈基於 ORM 的應用程式或不需要任何特殊例外狀況處理的應用程式(或兩者兼具),這種權衡可能是可以接受的。但是,Spring 允許透過 @Repository
註解透明地應用例外狀況翻譯。以下範例(一個用於 Java 組態,另一個用於 XML 組態)顯示了如何執行此操作
-
Java
-
Kotlin
@Repository
public class ProductDaoImpl implements ProductDao {
// class body here...
}
@Repository
class ProductDaoImpl : ProductDao {
// class body here...
}
<beans>
<!-- Exception translation bean post processor -->
<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>
<bean id="myProductDao" class="product.ProductDaoImpl"/>
</beans>
後處理器會自動尋找所有例外狀況翻譯器(PersistenceExceptionTranslator
介面的實作),並建議所有標記有 @Repository
註解的 Bean,以便發現的翻譯器可以攔截並在拋出的例外狀況上應用適當的翻譯。
總之,您可以基於純持久化技術的 API 和註解實作 DAO,同時仍然受益於 Spring 管理的交易、相依性注入以及透明的例外狀況轉換(如果需要)到 Spring 的自訂例外狀況階層。