2010-04-12 78 views
9

爲了說清楚,我並不是要求在SO上已經被問過廣告Nauseum的並排比較。我也不問Linq2Sql是否死了,因爲我不在乎。我正在問的是...爲什麼我應該使用Linq2SQL的實體框架

我正在構建內部應用程序只爲非營利組織。我是員工中唯一的開發人員。我們總是使用SQL Server作爲我們的數據庫後端。我也設計和構建數據庫。我已經成功使用過L2S了。

考慮到所有這些因素,有人會給我一個令人信服的理由來使用EF而不是L2S嗎?

我在代碼營本週末和EF,所有這一切,我可以在L2S做了一個小時的論證後,我問這個同樣的問題。演講者的回答是,「L2S已經死了......」那麼很好!不! (see here

我知道EF是MS希望我們在未來使用的(see here),並且它提供了更多的自定義選項。我無法弄清楚的是,如果在這種環境下,這些應該或者確實對我很重要。

我們在這裏遇到的一個特殊問題是我繼承了基於4個不同SQL數據庫的核心應用程序。 L2S在這方面遇到了很大的困難,但是當我問上述發言人時,EF會在這方面幫助我,他說:「不!

+0

任何人都在意詳細解釋投票嗎?這應該是一個CW或什麼的?我不介意被拒絕投票,我只想知道爲什麼我下次可以做得更好。 – 2010-04-14 00:17:26

+0

我在想你對多個數據庫的評論。困難在哪裏? Linq to SQL對DataContext有一個重載,允許您指定要打開的數據庫,並且在任何情況下連接都是多個數據庫的問題。 – 2010-04-16 16:37:40

+0

@Robert Harvey:困難在於這種情況......在一個名爲CMO的數據庫中有一個表名tblDiagnosisCues。在名爲MCP的數據庫中有一個名爲tblPlanDiagnosis的表。這兩個表由FK,DiagnosisCueID鏈接。當我想爲計劃拉動診斷時,我必須從CMO數據庫中獲取描述。我本來希望EF能夠通過讓我創建一個不關心數據來自哪裏的診斷實體來簡化這一過程。這更清楚嗎?由此,我沒有設計這些數據庫! – 2010-04-16 18:12:07

回答

8

藉助EF,您可以在類對象與數據庫表之間獲得一個映射層(即您的實體)。如果您需要這種靈活性,或者更喜歡domain-driven design模型(而不是表驅動設計),EF可能值得考慮。 Linq to SQL幾乎是一個類到表的映射器。

+0

所以,爲了自己澄清一下,你說的是作爲一個例子,如果我有數據庫,我無法控制EF將允許我創建對我的應用程序有意義的類,而不考慮L2S不會的表結構。 – 2010-04-12 16:57:51

+1

@Refracted:大部分。顯然EF不會彌補一個非常糟糕的數據庫設計,但它可以使事情變得相當順利。另外,有些人更喜歡基於域的設計,其中底層表實際上可能與實際的域對象不同。 – 2010-04-12 17:05:35

+0

@羅伯特哈維:那麼說公道的話,因爲我設計所有數據庫,除了前面提到的那些數據庫外,EF在這方面的優勢還是很小的。這是除非我設計一個蹩腳的數據庫,然後嘗試使用它。 – 2010-04-12 17:15:43

0

那麼,最後取決於必要條件。

現在你使用linqtosql,它適合你,但也許有一天你有更復雜的必要條件,你可以更好地與EF合作。例如使用速度或其他。

+0

沒有冒犯,但你基本上重申我的問題。我明白,英孚允許更多「複雜」,我不明白的是什麼? – 2010-04-12 16:56:08

+0

那麼,基本上你有這三個:會議在ORM的時尚,實體第一場景和分佈式caché。 – 2010-04-13 10:24:35

4

我經常想到這一點,因爲EF看起來比L2S增加了很多複雜性。由於MS正在積極開發EF,所以EF 4有一些新的方面值得關注。有一個nice summary on the ADO.NET team blog,它描述了EF的API如何演變以支持更廣泛的開發模式。

特別是,我個人感興趣的是支持POCO和存儲庫模式,因爲它們非常適合我工作的項目。在我看來,使用任何特定提供者的一個令人信服的理由是將來切換到完全不同的提供者是多麼容易(當然,沒有檢修所有的應用程序代碼)。我發現L2S缺乏這方面的內容(無論如何),我很高興看到EF 4的變化。但是,迄今爲止,我一直在閱讀有關EF 4中的這些變化,所以我可以「說他們實際上在實際工作中有多好。

1

當我第一次看到EF並且我已經在Linq2Sql中編寫了一個大型應用程序時,我問自己這個問題。最大的改變是在對象映射層完成的。在EF關係中,導航是爲您管理的。所以,如果我有一個有外鍵關係(比如寵物和業主)兩個表我可以做

pet.owner 

而在L2S我不得不寫的連接查詢自己。如果你有一個'純連接表'(這是一個帶有兩個外鍵但沒有其他數據的表),那麼這個表就不會在對象映射中表示。

您也可以自己處理急加載/延遲加載。

我也可以在POCO中開發,所以我沒有直接綁定到框架上,即我沒有L2S或EF類型的所有噪音妨礙,這使得測試方法更容易。

總體而言,我更喜歡EF但情況因人而異

+0

很棒的回答!我很好奇,而且我會自己嘗試驗證這一點,但是,關於'pet.owner'的觀點我認爲在L2S中也是可以的。我可能會誤解,我會去看看我的代碼,我認爲我在做這件事。雖然你的其他觀點看起來很有效,但讓我思考。 – 2010-04-13 12:45:11

+0

pet.owner - 可能 - 自從我使用它之後有一段時間 - 我必須回去檢查,也許其他人可以確認 – 2010-04-13 12:54:42

+3

@Refracted:如果Linq to Sql設計器中的兩個表之間存在關係,那麼您確實可以通過這種方式通過'pet'對象,並抓住'owner'。 – 2010-04-14 19:12:46

0

實體框架具有更好的兼容性,如果你希望你的應用程序擴展到其他DBMS,這是它的一個主要優勢。

實體框架將在DBMS比的Microsoft SQL Server等,如Oracle,MySQL的等

工作時的LINQ僅限於MS SQL服務器。

+0

感謝您的回答,但如果您會注意到,在我原來的文章中......「*我們總是使用SQL Server作爲我們的數據庫後端。*」所以這在這種情況下對我來說並不是真正的優勢。 – 2010-04-13 13:24:46

+0

Linq to SQL then – GenEric35 2010-04-13 23:22:59

0

L2S允許隱式延遲加載,而EF具有明顯的延遲加載。在一個小型項目中,在L2S中完成的隱性工作肯定不錯,對於快速開發很有好處,但對於較大的項目,開發人員可能需要更多地控制應用程序調用的數據庫資源。

http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx

+1

不適用。在EF 4中,您可以選擇懶惰或渴望。 – 2010-04-13 21:42:45

3

EF是面向要全力以赴ORM在您的對象模型是顯著不同,那麼你的數據庫架構。 L2S更多的目標是成爲一個快速的DAL生成器。

問題是EF是一個平庸的ORM,而L2S是一個非常棒的DAL生成器。

我會說如果L2S符合您的需求,請保持它,不要讓MS營銷推動你。如果L2S沒有做你需要做的事情,並且你需要留在微軟產品中,那麼就去EF吧。如果你對自己的技術有一定的自由度,請查看NHibernate和LLBGen(imo都比EF好)

0

我前段時間從Linq2Sql切換到實體框架,用於我的所有項目。最初它在幾個方面倒退了一步 - 在Linq2Sql中工作得很好的日期表達式在EF中不起作用,並且沒有延遲加載選項。但是現在,使用Entity Framework 4一切正常。

如果只是你,你沒有時間學習EF,請堅持使用Linq2Sql。但是如果你有時間並且認爲你可能最終需要其他形式的繼承,而不是表中或EF的其他功能,那就去吧!

你應該做出這個轉變的第一個理由:實體框架體驗在​​你的簡歷中看起來不錯!

2

他們都是非常錯誤的。自從我在一個月前開始使用Entity Framework以來,我發現了8 bugs(兩個影響L2S,至少有三個仍然存在於EF4中)。這是我一生中最痛苦的經歷之一。

但是,如果EF按照他們想要的方式工作,那麼類和表的分離將非常好。

7

我很大的原因使用LINQ2SQL是,它有一個顯著implcit設計缺陷:

使用一個DataContext建議的最佳做法是,它可以在短暫的「工作單位」使用風格。很好,除了首先繼續創建和處理這個價格適中的對象。

當您想要反序列化或重新創建一個對象(可能來自提交的網頁),然後更新現有記錄時,會出現問題。 Linq-to-sql提供的Attach方法將只接受以下三種情況:

  1. 您可以在所有表​​上實現時間戳。
  2. 您重新選擇要更改的實體,然後更改並提交。
  3. 你神奇地碰巧仍然有對象的原始版本。

第一個場景請求數據庫更改,這對於某些環境是不可接受的。 第二種情況是右下效率低下 - 爲什麼檢索你已有的數據? 第三種情況是不現實的 - 無狀態web應用程序通常不會保留歷史信息。

這裏的重點是... EF4.0允許您將對象重新附加到ObjectContext並將其標記爲已添加或新建,並且上下文將相應地生成正確的INSERT/UPDATE語句。

+0

這是怎麼沒有被投票?最好的答案。 – nathanchere 2010-09-22 23:56:01

相關問題