大型，可擴展和可維護的Web應用程序中的ORM或SQL？

Question

我知道網上已經有很多關於這個話題的帖子。

然而，許多人在談論它時往往會關注不同的事情。 我的主要目標是創建易於維護的可伸縮Web應用程序。 開發和維護的速度遠遠超過原始性能（或者我可以使用Java）。

這是因為我注意到當項目代碼大小增長時，您必須具有可維護的代碼。 當我第一次以程序方式編寫我的應用程序時，沒有任何框架，它只在1個月后成為一場噩夢。 我完全迷失在意大利面條代碼行的叢林中。 我根本沒有任何結構，即使我努力實施一個。

然后我意識到我必須有正確的結構和代碼。 我開始使用CodeIgniter。 這真的給了我結構和可維護的代碼。 許多用戶說框架正在減慢速度，但我認為他們錯過了這個畫面。 代碼必須易於維護且易於理解。

Framework + OOP + MVC使我的Web應用程序結構化，以便添加功能不再是問題。

當我創建模型時，我傾向於認為它代表了一個數據對象。 也許是一個表格甚至一個表/數據庫。 所以我想到了ORM（學說）。 也許這將是我的Web應用程序的另一個偉大的實現，給它更多的結構，所以我可以專注於功能而不是重復自己。

但是，我之前從未使用任何ORM，我只學習了它的基礎知識，為什么它的使用效果很好等等。

所以現在我問你們所有像我一樣的人都在努力尋找可維護的代碼，並且知道這有多重要，ORM（doctrine）是否必須具備可維護代碼，就像framework + mvc + oop一樣？

我想要比“原始sql更快”的建議更多的生活經驗建議，因為如果我只關心原始性能，我應該首先放棄框架+ mvc + oop並保持生活在編碼噩夢中。

感覺它非常適合MVC框架，其中模型是表格。

現在我在一個文件中有150個sql查詢，做一些簡單的事情，比如通過id獲取條目，按名稱獲取條目，通過電子郵件獲取條目，通過X獲取條目等等。 我認為ORM可以減少這些行，否則我很確定將來會增長到1000 sql行。 如果我改變一列，我必須改變所有這些！ 真是一場噩夢再次思考它。 也許這也可以給我很好的模型，適合MVC模式。

ORM是采用結構和可維護代碼的正確方法嗎？

Answer 1

Ajsie，

我的投票是針對ORM。 我使用NHibernate。 它並不完美，並且有一個相當大的學習曲線。 但代碼更易於維護，更多OOP。 除非你喜歡大量的重復代碼，否則幾乎不可能在沒有ORM的情況下使用OOP創建應用程序。 它肯定會消除你絕大多數的SQL代碼。

而這是另一回事。 如果您打算構建一個OOP系統，那么無論如何您最終都會編寫自己的O / R Mapper。 您需要調用動態SQL或存儲過程，將數據作為讀取器或數據集，將其轉換為對象，將關系連接到其他對象，將對象修改轉換為sql插入/更新等。您所寫的將是比NHibernate更慢更多的錯誤或長期在市場上出現的東西。

您唯一的另一個選擇是構建一個以數據為中心的程序性應用程序。 是的，它可能在某些領域表現更快。 我同意表現很重要。 但最重要的是它的快速足夠。 如果你在這里和那里保存幾毫秒的程序代碼，你的用戶將不會注意到性能的提高。 但是你會注意到糟糕的代碼。

ORM中最大的性能瓶頸是以預取和延遲加載對象的正確方式。 這會導致ORM的n查詢問題。 但是，這些很容易解決。 您只需要對對象查詢進行性能調優並限制對數據庫的調用次數，告訴它何時使用連接等.NHibernate還支持豐富的緩存機制，因此您根本不會訪問數據庫。

我也不同意那些表示性能與用戶有關並且維護是關於編碼員的人。 如果您的代碼不易維護，那么添加功能將會出錯並且速度很慢。 您的用戶會關心這一點。

我不會說每個應用程序都應該有ORM，但我認為大多數都會受益。 另外，不要害怕在必要時偶爾使用帶有ORM的本機SQL或存儲過程。 如果您必須對數百萬條記錄進行批量更新或編寫非常復雜的報告（希望針對單獨的非規范化報告數據庫），那么直接SQL就是可行的方法。 將ORM用於OOP，事務，業務邏輯和CRUD，並將SQL用於異常和邊緣情況。

我建議在NHibernate和Onion Architecture上閱讀Jeffrey Palermo的內容。 另外，參加他的敏捷訓練營或其他課程來學習O / R Mapping，NHibernate和OOP。 這就是我們使用的：NHibernate，MVC，TDD，依賴注入。

Answer 2

許多用戶表示框架正在減慢速度，但我認為他們錯過了大局。 代碼必須是可維護的，並且易於理解。

如果它的性能是Teh Suck，那么結構良好，高度可維護的系統就毫無價值！

可維護性是使構建應用程序的編碼人員受益的東西。 原始性能有益於將應用程序用於其工作（或其他）的真實人員。 那么，他們的關注應該是最重要的：構建系統的人還是那些付錢的人？

我知道這並不是那么簡單，因為客戶最終會為結構不合理的系統付出代價 - 可能是更多錯誤，肯定有更多時間來修復它們，有更多時間來實現應用程序的增強功能。 通常情況下，一切都是權衡。

Answer 3

我開始像你一樣開發，沒有orm工具。

然后我為軟件開發更加工業化的公司工作，他們都使用某種orm映射工具（具有更多或更少的功能）。 開發更容易，更快，生成更易維護的代碼等。

但我也看到了這些工具的缺點：性能非常慢。 但這主要是誤用了該工具（在這種情況下是休眠）。

Orm工具是非常復雜的工具，因此很容易誤用它們，但如果你有使用它們的經驗，你應該能夠獲得與原始sql幾乎相同的性能。 我會給你三個建議：

• 如果性能不是很關鍵，請使用orm工具（選擇一個好的工具，我不用php開發，所以我不能給你一個名字）
• 確保添加的每個功能，檢查orm工具生成並發送到數據庫的sql（例如，感謝日志記錄工具）。 想一想，如果這是你編寫查詢的方式。 orm工具的大部分效率低下來自從db收集的不需要的數據，分成多個的獨特請求等。緩慢很少來自工具本身
• 不要將工具用於一切。 在不使用它時明智地選擇（每次進行原始數據庫訪問時都會降低可維護性），但有時候，嘗試使orm工具執行未開發的操作並不是最糟糕的。

編輯：Orm工具對於非常復雜的模型最有用：實體之間的許多關系。 這是應用程序的配置部分或應用程序的復雜業務部分中遇到的大部分時間。 因此，如果您只有很少的實體，並且它們被更改（重構）的可能性更小，那么它就沒用了。

少數實體與許多實體之間的界限尚不清楚。 我想說50個不同的類型（sql表，沒有連接表）很多，少於10個很少。

我不知道用於構建stackoverflow的是什么，但它必須經過非常仔細的性能測試。

如果您想構建一個負載如此繁重的網站，並且如果您沒有這方面的經驗，請嘗試讓您的團隊中的某個人已經在這些網站上工作過（使用一組真實的數據進行性能測試）並且代表性數量的並發用戶不是一個容易和快速的任務來實現）。 擁有經驗的人將大大加快這一過程。

Answer 4

保持穩定性非常重要。 我開發了具有低級超高性能的大規模Web應用程序。 最大的缺點是維護系統，即開發新功能。 如果你慢慢開發，客戶將尋找其他系統/應用程序..它的交易。 如果你需要直接對sql進行optmized查詢，大多數orms都有功能。 orm本身不是瓶頸。 我會更多地談論一個好的數據庫設計。

Answer 5

我想你錯過了這張照片。 每天為用戶提供性能，他們完全不關心可維護性。 你是種族中心主義者，你只關心你的個人關注，而不是那些支付系統費用的人。 這不僅僅是為了您的便利。

也許您應該與用戶坐下來觀看他們使用您的系統一兩​​天。 那么你應該坐在一台與他們使用的PC（不是開發機器）相同功率的PC上，花一整個星期做什么，除了整天使用你的系統。 那么你可能會理解他們的觀點。