從JPA遷移回簡單的SQL

經過多年的TopLink/EclipseLink在包含大約100個表的生產應用程序的開發之後，我們認爲足夠了，JPA不值得增加其實際操作的複雜性和不確定性，而且SQL（包含像DBUtil或類似的包裝器）可以爲我們完成這項工作。從JPA遷移回簡單的SQL

您能否建議如何將一個非常大的JPA應用程序遷移到JDBC/SQL，以便讓JPA仍然運行（即在帶有GUI的webapps中），但是這樣可以讓我們仍然以「降級「到JDBC？我們有實體和DAO，但我真正擔心的是JPA entitycache（主要的） - 是否可以完全禁用它，以便JPA充當簡單的connection.begin（）;條目... connection.commit（）;在此期間，直到我們擺脫它爲好？

來源

2013-04-06 bozo

我可以推薦Spring JDBC模板。您可以完全控制正在執行的SQL，而無需使用JDBC鍋爐代碼的麻煩。 – 2013-04-06 09:35:03

你好，抱歉，但這不是一個答案。我知道JDBC模板和Apache DBUtils（已經使用它們），它們都很好，但我的問題是關於如何在並行運行JPA時啓動遷移的建議。 – bozo 2013-04-06 09:55:41

我希望你們有一些很好的單元和集成測試。如果不是，那麼這是從哪裏開始的。

之後，在第一步中，您可以創建一個abstract factory，通過它可以訪問所有DAO和實體，並更改客戶端訪問該工廠的所有訪問權限。在這一步中，您必須爲該工廠提供一個實現，創建一個具體工廠JpaAccessFactory並讓其方法返回使用JPA填充的DAO和實體。

當你確定沒有什麼不好的第一步。然後繼續第二步。

創建一個工廠實現SqlAccessFactory女巫使用SQL填充DAO和實體（實體類的對象實際上只是DAO）。寫一些女巫使用兩個工廠的單元測試，並使用提供的expected和SqlAccessFactory提供的actual進行斷言。

當你完成了一個表及其所有依賴項的工廠方法在SqlAccessFactory中的實現時，讓使用此方法提供的DAO或實體的客戶端/頁面使用新工廠來檢索它。你可以使這個可配置的，所以你不必更改代碼來改變工廠正在使用。如果你發現事情不像應該的那樣，這也有利於輕鬆切換回來。

工廠方法女巫尚未SqlAccessFactory實現可能只是拋出一個異常

throw new UnsupportedOperationException 
    ("Not yet implemented, please configure your client/page to use JPA.");

我希望這給一些提示一個在哪裏以及如何開始。

來源

2013-04-06 10:51:24 A4L

你好。從算法上看，你的答案沒問題，但是我看到的問題是，當JDBC更改實體時 - >由於主緩存/實體上下文，這不會反映在JPA中。那麼最後呢，這種移民似乎必須以「全部或全部」的方式來完成呢？只是澄清 - 這不是一個簡單的web應用程序，但JPA由3個webapps和EJB模塊使用（它將在JPA緩存IMO中具有無效數據）。 – bozo 2013-04-06 12:08:53

是的，這將是一個「全部或全部」重構的最小單位儘可能女巫是一個數據庫表及其所有依賴項（角色/集合）和對它們的所有操作。試圖關注jpa功能和thire「副作用」，你將最終實現自己的jpa。 – A4L 2013-04-06 12:56:03

一個想法是引入一個存儲庫層。您可以引入存儲庫並使用JPA快速實現核心api，可能會重用相當多的現有數據訪問代碼。

問題是，在同一時間，您開始重構整個應用程序以直接使用存儲庫而不是JPA。

然後，另一個團隊可以在使用純jdbc實現的存儲庫上工作，並根據jpa實現測試jdbc實現 - 由於jdbc和jpa存儲庫實現相同的一組接口，所以一致性測試是顯而易見的。

總結，以下發生在同一時候：

您設計您的界面層，以滿足實際業務代碼
你現有的JPA代碼來實現倉庫的需求
你重構業務代碼使用存儲庫
您使用jdbc實現相同的存儲庫並執行一致性測試

就是這樣。當有足夠的信心時，只需將存儲庫實現切換到jdbc存儲庫，並僅保留jpa存儲庫以進行向後兼容性測試。

來源

2013-04-06 10:54:49

對不起，我不能接受這兩個答案，因爲你的也很好，所以我剛剛提出了你的答案。 – bozo 2013-04-07 12:17:33

從JPA遷移回簡單的SQL

回答

相關問題