JPA與JDBC，存儲過程和公司或如何說服老派程序員嘗試ORM？

Question

這是我定期處理的事情，第一次是我需要信念。 幸運的是，我只是嘗試過，做了額外的努力來學習並感謝本書 ，Spring支持和Hibernate我不會在不考慮JPA的情況下啟動項目。 但並不是每個人都願意經常加倍努力（就在我猜的任何事情中）。 那么如何以及如何說/提出/解釋/論證至少改變他們對ORM的態度？

相關： 說服頑固的DBA使用ORM來處理大多數CRUD與存儲過程，視圖和函數

Answer 1

我假設你實際上有一個比單純的DTO更豐富的對象模型，而不僅僅是與你的關系模式的1：1對應關系。 如果沒有，你就不會贏得爭論。

如果Hibernate生成的SQL至少與存儲過程中的手動編碼內容一樣有效，那么您就贏了。

如果可以優化存儲的proc以比Hiberate生成的SQL更好地執行，則會丟失。

如果數據庫由依賴於存儲過程的其他應用程序共享，則會丟失。 您不能輕易地將邏輯移動到Spring和中間層。

如果您的應用擁有數據庫，那么您有一個更好的案例。

由於您已經在使用Spring，這表明您有一個利用Spring Validation的DAO層。 PreparedStatements已在下面使用，因此對於Spring而言，SQL注入與存儲過程一樣不太可能。

Answer 2

好的，我將在這里扮演魔鬼的擁護者。

存儲過程是一個抽象層。 JPA要求您了解基礎表結構。 存儲過程/函數掩蓋了; 你只需要知道要調用的過程或函數以及它的返回類型。

JDBC使用Connection對象的prepareCall方法可以非常輕松地調用存儲過程。

存儲過程還增加了一層安全性：應用程序本身通常無法手動修改表，只調用執行修改的過程。 SP / SF還應該驗證傳遞給它的參數。

存儲過程的主要缺點是恢復數據......您需要創建自己的工具來映射返回Java對象的數組和結構，通常使用類型Map和實現SQLData接口的特殊編程創建對象。

Answer 3

那么如何以及如何說/提出/解釋/論證至少改變他們對ORM的態度？

詢問他們是否要為您添加到應用程序的每個新實體類型繼續編寫相同的樣板SQL JDBC CRUD代碼。

如果數據層中沒有ORM解決方案，則每個新實體類都需要N個工作單元才能通過數據層（DAO，CRUD代碼，存儲過程，編寫查詢等）使該實體可用。

ORM將N轉換為自身的一小部分，假設添加新實體然后要求您只在元數據中為該實體添加另一個映射。

Answer 4

你的問題的答案實際上非常簡單，完全獨立於你是否是一個頑固的DBA。 你必須問自己：

您是否正在編寫具有大量CRUD的以域模型為中心的應用程序？

或者您是否正在編寫以關系模型為中心的應用程序而不是那么多的CRUD？

在第一種情況下，選擇ORM。 在第二種情況下，選擇SQL。 如果您的應用程序中同時包含兩者，請選擇兩者。 這兩種模式並不是相互排斥的，雖然奧姆斯做強加很多規則上的應用設計。

請注意，ORM不是Java世界中的“下一件事” 。 它們是一個偉大的發明，只能解決一些問題（即復雜或重復的CRUD）

Answer 5

更少的樣板和額外的安全性。 你可以保存你的手指，初級程序員引入SQL注入漏洞的機會較少，我認為這些漏洞非常重要。

Answer 6

我認為來自相關問題鏈接的答案指出了潛在的問題。 如果數據庫的目的與您的應用程序緊密耦合，並且它實際上沒有單獨的標識，那么ORM會有很多意義。

但是，如果您的數據庫代表了更大的圖片並且您的應用程序是訪問數據的眾多應用程序之一，則使用ORM可能會對應用程序與數據庫之間的耦合以及隨時間更改數據庫的需求產生潛在的負面影響。

但在某種程度上，你可以自己回答你的問題 - 你有什么異議？ 你是怎么第一次說服的？

Answer 7

ORM為應用程序中的錯誤提供了一半的機會，而另一方面，存儲過程使錯誤的機會增加了一倍。

如果應用程序中存在錯誤，您必須考慮：它是代碼還是存儲過程的一部分。

此外，您如何單獨測試SP？

請記住，代碼中的錯誤和數據庫中的錯誤可以很好地加倍，以創建一個有效的解決方案。 就像數學中的兩個負面因素一樣積極。 當SP修復而不修復代碼時，它變得混亂，反之亦然。