ORM：是或否？

10

你可能想看看這個問題前面，其中討論的ORM的好處：What are the advantages of using an ORM?

最相關的部分（從接受回答）：

如果你有複雜的，手工已調整的SQL，使用ORM的沒有多少意義。

如果您經常到達ORM並編寫自己的SQL，那麼ORM可能最終會妨礙您的工作。

來源

2009-05-05 16:38:59

+0

「複雜的，手動調整的SQL」是什麼意思？我認爲ORM可以處理你在SQL中可以做的任何事情。 – johnny 2009-05-05 17:11:43

+0

ORM能夠處理任何*你可以在SQL中執行的任何操作，特別是當你考慮特定的SQL時（在這種情況下是Oracle的）。如果您需要使用Oracle的特定功能，那麼您可能需要用SQL編寫至少幾個查詢，而不是ORM的對象查詢語言。 – 2009-05-05 17:52:44

+0

我不得不通過ORM並編寫自己的SQL的最常見的地方是報告。有些報告可能會變得非常複雜，我認爲任何ORM都不會使用PIVOT。 – Min 2009-05-05 20:07:43

1

這取決於...

而且你不必使用ORM爲每個數據庫訪問...

來源

2009-05-05 16:40:33 pgras

5

因爲即時通訊不允許發表評論您的文章生病的評論是這樣的（缺少點）。

適合討論爲什麼你不喜歡ORM。

伊莫，我會去的。如果你由於某種原因找到了一個由ORM緩慢的查詢，那麼我會自己做。僅僅因爲你使用了ORM，你的大部分任務並不意味着你必須使用它。但是，是的，這將是首選。

來源

2009-05-05 16:43:10

3

ORM的另一個優點是它對你的簡歷看起來非常好。今天廣告的大多數工作（至少Java開發人員）都需要一些關於ORM的知識。所以如果你有機會參與一個項目，我會選擇Spring和Hibernate，因爲它會真正提升你的簡歷。

我認爲其他問題的鏈接涵蓋了技術上的好處，所以我不會對它們說些什麼。

來源

2009-05-05 16:43:50 willcodejavaforfood

1

是的。 ORM可能會給應用程序開發人員帶來很多負擔;至少，設計時應該不會給設計增加太多的負擔，並且如果您決定使用ORM，將來可能會有很大的幫助。

來源

2009-05-05 16:44:15

1

像其他人一樣提到;如果你是嚴重依賴於數據庫的話，ORM會給出小問題，只是添加不太有用的抽象。但最重要的是：你（想）將數據作爲對象處理還是不處理？如果是，ORM就是爲此而設計的。如果沒有，爲什麼要麻煩。如果需要，您可以稍後添加ORM - 可能比預先花費更多的時間，但是做相反的事情（在Hibernate發生故障後取消Hibernate）會更糟糕。

但是ORM之間也有差異;例如，iBatis可能比Hibernate更適合（對於這個特定主題還有其他問題）。

來源

2009-05-05 16:45:59 StaxMan

5

我個人發現他們（好吧，休眠）是一個令人難以置信的時間下沉。除了節省時間之外，我花了太多時間試圖弄清楚它究竟在封面下究竟做了什麼。正如其他人所提到的，如果您的數據模型增長超過一定的複雜度，那麼在您和數據庫之間建立另一個層就會產生更多的摩擦。如果你的數據模型不那麼複雜，那麼你不需要ORM。

我做建議有某種抽象，以保持你的Java代碼的SQL，但可以簡單地使用DAO層和屬性文件或任何其他。另外像IBATIS或Spring JDBC工具可以是有益的，因爲你仍然可以編寫自己的查詢，並只需使用框架，以幫助所有的樣板代碼爲JDBC和你的模型對象之間的洗牌數據。

PS：有趣的邊注。在我的辦公室裏，我們實際上有一張加文國王的畫像，我們都在肖像中詛咒。「嘿，這是你的輪到應對今天的Hibernate的問題，所以這裏的加文。」 :-)

來源

2009-05-05 18:06:04

2

的ORM故意解耦從數據庫中你的工作對象，創建一個抽象（不可避免地泄漏）。所以你最終只能通過隧道恢復你想要消除的東西。

如果有很多應用程序的數據庫是故意實施，那麼ORM只是增加噪聲的信號 - 和衰減的信號。

來源

2009-05-05 18:19:03 dkretz

1

OR映射確實可以爲您的特定數據庫的SQL的一個問題。但是，OR映射的一些概念非常強大，並且可以更輕鬆地與數據庫進行交互。許多OR映射器常見的一些概念是：

爲您的數據庫模式生成代碼。
類型安全（某些奧姆斯）
更強大的變量比被物體通過JDBC提供
SQL組成的結合，以避免SQL語法錯誤

您的任務一個很好的工具，可以http://jooq.sourceforge.net ，它允許你創建你想要的任何SQL（包括嵌套選擇，聯合，複雜聯接，別名，存儲過程，UDT等）。

來源

2010-11-26 22:22:30

3

我個人更喜歡儘可能接近SQL，所以我會用iBatis ，JOOQ或MentaBean。順便提供了一種儘可能接近SQL的方法，同時爲樣板JDBC代碼提供了很多幫助。

來源

2011-09-24 19:53:05 TraderJoeChicago

1

ORM：是的，對於像軟件這樣的公司來說，數據是複雜的...多層次，表格，圖層...但即使在這裏，NHibernate和EF6以及數據庫視圖的組合也是值得推薦的。

不適用於任何特殊應用程序。像測量和你需要真正節省了大量的數據，但沒有數據的複雜性

隨着ORM有多種可能性，一切都取決於你想要什麼。

作爲一個真正的ORM映射器我強烈推薦NHibernate和流利NH映射。你需要進行大量的研究才能把一個很好的建築放在一起，但是沒有任何東西可以阻擋你。以最小的折衷方案，您可以獲得真正的靈活性

EF6x（核心不是產品就緒恕我直言）被稱爲ORM，但它生成的更接近DAL。有些東西你不能用EF6有效地完成。儘管如此，這是我最喜歡的讀取模型工具，但我將它與NHibernate（NH用於DDD /寫入模型）結合使用。

現在到表現 - 它總是正反兩面。如果您深入瞭解ORM 體系結構（請參閱我的文章：avoid ORM bad habits），那麼您會直觀地找到使其更快的方法。這是我的另一篇文章，關於如何使EF6x 5x 更快（至少在讀取情況下）：EF6.x 5x faster

來源

2017-02-26 15:02:27 baHI

ORM：是或否？

回答

相關問題