JPA是Java EE 5很重要的一部分，它的采用大大簡化了Entity Bean的使用。但JPA有一個很明顯的缺陷，就是無原則地采用JPA，就有可能將數據庫結構移植到你的應用程序的代碼中。這將給應用程序的維護和升級帶來麻煩。

本文講的“無原則地采用JPA”，主要指通過Annotation對Entity Bean之間的關系進行定義。這些數據實體的關系，如一對多，一對一，多對一，多對多及關聯操作（cascade）等，很明顯是數據庫概念。為了實現ORM的目的，JPA不得不將其在Entity源代碼中定義這種關系。

這在很大程度上，將數據庫的結構與設計移植到了應用程序中。這有以下幾個問題：

一，應用程序源代碼可讀性差數據庫結構的復雜程度，幾乎完全取決于應用的業務邏輯。如果業務邏輯復雜，對Entity Bean的關系定義將很困難?？梢韵胂?，其代碼的可閱讀性將很差。

二，應用程序的可維護性差一旦數據庫結構因業務需求而發生變化，這些關系將需要重新定義。

三，對較復雜的數據庫結構關系進行定義幾乎是不現實的這也是ORM本身的局限性。將數據庫結構移植到應用程序中本身就是個錯誤方向。關系數據庫主要在于“關系”二字，因為數據庫關心的是數據及其完整性（Data）。而應用程序采用OOP的開發手段，關心的是系統內部各“物件（Object）”的動作（Operation）。數據是應用程序的狀態；動作是應用程序的業務邏輯。狀態和動作是構成應用程序的兩大要素，二者缺一不可。而ORM試圖忽視狀態而抬高動作，豈不知“動作”的最終結果要落實在“狀態”的改變上。想一想，為什么Object Database Management System （ODBMS）不太流行呢？

【編輯推薦】

1. 持久化規范JPA(JavapersistenceAPI)
2. 9.3 從特定的API到混搭
3. Java簡單框架 JPA框架比較