簡體 English 中英

代碼生成器與ORM與存儲過程

[英]Code generators vs. ORMs vs. Stored Procedures

原文 2008-09-16 20:09:58 8 6 language-agnostic/ architecture/ stored-procedures/ orm/ code-generation

這些軟件體系結構在哪些領域發揮作用或失敗？

哪些關鍵要求會促使您選擇其中一個？

請假設您有開發人員可以做好面向對象的代碼以及良好的數據庫開發。

另外，請避免神聖的戰爭:)這三種技術都有利有弊，我對哪種方式最適合使用感興趣。

6 個解決方案

這些工具中的每一個都提供不同的抽象層，以及覆蓋行為的不同點。 這些是架構選擇，所有架構選擇都取決於技術，控制和組織之間的權衡，包括應用程序本身和部署它的環境。

如果您正在處理DBA“掌控”的文化，那么基於存儲過程的架構將更易於部署。 另一方面，管理和版本存儲過程可能非常困難。
使用靜態類型語言時，代碼生成器會發光，因為您可以在編譯時而不是在運行時捕獲錯誤。
ORM是集成工具的理想選擇，您可能需要在安裝到安裝的基礎上處理不同的RDBMS和模式。 更改一個地圖，您的應用程序將從使用Oracle上的PeopleSoft到使用SQL Server上的Microsoft Dynamics。

我已經看到了使用Generated Code與存儲過程進行交互的應用程序，因為可以調整存儲過程以繞過代碼生成器中的限制。

最終，唯一正確的答案將取決於您嘗試解決的問題以及解決方案需要執行的環境。 還有其他東西在爭論'馬鈴薯'的正確發音。

我加上我的兩分錢：

存儲過程

可以輕松優化
抽象的基本業務規則，增強數據完整性
提供良好的安全模型（無需向前端數據庫用戶授予讀取或寫入權限）
當您有許多應用程序訪問相同的數據時閃耀

奧姆斯

讓您只關注域，並采用更“純粹”的面向對象的開發方法
當您的應用程序必須與數據庫兼容時，請發光
當您的應用程序主要由行為而不是數據驅動時，請發光

代碼生成器

為您提供與ORM類似的好處，具有更高的維護成本，但具有更好的可定制性。
通常優於ORM，因為ORM傾向於為運行時錯誤交換編譯時錯誤，這通常是要避免的

我同意一切都有利有弊，很大程度上取決於你的架構。 話雖這么說，我嘗試在有意義的地方使用ORM。 許多功能已經存在，通常它們有助於防止SQL注入（加上它有助於避免重新發明輪子）。

有關更多信息，請參閱有關該主題的其他兩篇帖子（動態SQL與存儲過程與ORM）

動態SQL與存儲過程
哪個更好：即席查詢或存儲過程？

ORM與存儲過程
為什么NHibernate生成的參數化SQL和存儲過程一樣快？

ORM和代碼生成器位於字段的一側，存儲過程位於另一側。 通常，在綠地項目中使用ORM和代碼生成器更容易，因為您可以定制數據庫模式以匹配您創建的域模型。 將它們與遺留項目一起使用要困難得多，因為一旦軟件使用“數據優先”思維模式編寫，就很難用域模型進行包裝。

話雖如此，這三種方法都有價值。 存儲過程可以更容易優化，但是可能很容易將業務邏輯放在其中，這些邏輯可能會在應用程序本身中重復出現。 如果您的模式與ORM的概念匹配，ORM可以很好地工作，但如果沒有，則很難自定義。 代碼生成器可以是一個很好的中間層，因為它們提供了ORM的一些好處，但允許自定義生成的代碼 - 但是，如果你養成改變生成的代碼的習慣，那么你有兩個問題，因為你每次重新生成它時都必須改變它。

沒有一個真正的答案，但我更傾向於ORM方面，因為我認為用對象優先思維思考更有意義。

您忘記了一個值得擁有自己類別的重要選項：混合數據映射框架，例如iBatis 。

我對iBatis很滿意，因為它讓你的OO代碼本質上保持OO，你的數據庫本質上仍然是關系的，並通過添加第三個抽象（對象和關系之間的映射層）來解決阻抗不匹配問題。映射兩者，而不是試圖強制將一個范式強加到另一個范例中。

存儲過程