我搜索了....我看到很多優點，但似乎所有優點都來自於在線SQL比較。我知道內聯SQL是不好的。但爲什麼要與壞的比較來更好地展示其他？使用ORM工具（框架）的優勢？
如果使用存儲過程（可能是專有的），似乎沒有任何優勢依然存在。存儲過程在安全性和性能方面肯定提供了性能優勢（如果ORM可以超出存儲過程，那麼存儲過程就寫得很糟糕），而且寫得很好的存儲過程就是自動存儲庫（模式）。存儲過程絕對可以提供更好的事務和事務隔離控制。
我真的很感激答案 - ORM如何在使用存儲過程的架構良好的應用程序上更好。
---感謝所有我收到到目前爲止的答案......看來，優勢仍然來自使用ORM的「動態生成的SQL」比較使用「靜態寫入行SQL」中代碼。是的，它有優勢。但這不是他的問題。
的問題是更好的表述爲以下幾點：
如果考慮具有存儲過程來實現你的業務邏輯（SPS可以寫很先進，也很有效），在應用程序代碼（.NET ，JAVA），您可以根據業務需要組織非常簡單的存儲過程層包裝。我的問題是ORM如何超越這個架構（當然是設計良好的架構）。
ORM工具使得可以在OO環境中開發數據庫和模型之間的抽象層。該層的主要優點是不熟悉SQL的開發人員可以使用該模型。
這不一定是因爲軟件工程師不熟悉SQL。我突然意識到，在很多地方，內聯SQL仍然是開發應用程序時使用的數據訪問方法。在這些地方，ORM工具肯定是非常棒的。是。 ORM優勢的結論是將其與在線SQL進行比較的結果。 – 2011-06-04 01:49:55
我一直在尋求一個很好的答案。這是我覺得有所作爲的：
1）ORM增加了開發人員的生產力 - 將域類映射到數據庫更容易。 2）存儲過程可能包含業務邏輯 - 很難測試這些。這主要是因爲缺乏工具/嘲笑框架。 3）ORM框架是經過測試的，它爲您提供開箱即用的緩存功能 - 無需重新發明輪子 - 在大多數應用中，我已經看到哪些不使用任何ORM功能最終編寫內部數據層ORM開箱即用。這就是說--ORM確實也增加了一些開銷，並且它需要開發人員意識到一個新的平臺 - 編寫高效的映射隨實踐而來，因此存在一條學習曲線。
在現代設置中，網絡帶寬不如開發速度快，質量好（經過嚴格測試）的代碼。我想這使得ORM非常適合數據庫驅動的應用程序。
ORM是一種工具，可用於構建您所謂的「架構良好的系統」。我們的想法是，當您使用非關係語言進行開發時，SQL /存儲過程提供的關係操作集與用於構建應用程序其餘部分的語言之間將存在impedance mismatch。
對於使用面嚮對象語言（無論是C++，C＃還是Java）的開發人員，在將複雜關係模式映射到豐富域模型時需要考慮很多事項。這當然是可以執行自己的代碼的所有這種映射的，但你在這個面向對象和關係範例之間「無無人區」的互動變得更加複雜更加有用的ORM引擎和相關工具即可。
爲你規劃出你的映射層的一些考慮：
DataSet）？另一個考慮事項，特別是在團隊中工作時，當與領域層關係映射是手工完成時，開發人員編寫映射的方式可能會有很大差異。這可能會導致難以檢測到的不一致，重疊和差距。一個ORM（尤其是衆所周知的/牢固樹立ORM）的選擇可以對解決方案和圍繞該ORM將決定你如何想象映射層的預現有的社區產生巨大的（希望是積極的）影響（你會發現，例如，Spring.NET和Entity Framework用戶之間存在顯着的文化差異）。
是否一個ORM使一個很好的架構？不。有沒有系統的架構會比ORM更好？肯定。有沒有項目因不必要的ORM添加而癱瘓？我猜測有很多。
我建議從不同的角度接近這個問題，並將其應用到您正在使用的具體應用。通過使用ORM可能解決的SQL和/或存儲過程，您是否有任何難題？您是否發現任何風險或對導入ORM可能導致的問題有任何顧慮？只有權衡這些問題的答案，您才能確定ORM是否適合任何給定的解決方案。
老實說。在現實世界的許多應用程序中，我從來沒有遇到過「存儲過程」難以解決的問題。 – 2011-06-04 02:02:42
我沒有看到一個ORM如何必然是正交存儲過程。 SPROC定義了一個面向動作的接口，但是ORMs（甚至那些不試圖在關係模型上強制使用OO概念的ORM）關注於暴露表以外的模型中的數據 - 例如一個明確定義的元組（或對象）的列表。一些ORM將允許使用適當的SPROC操作，而另一些則完全避免SPROC。所以......「這取決於」。 – 2011-06-03 05:13:26