none
請問DataSet、LINQ與EntityFramework資料存取技術? RRS feed

  • 問題

  • 請問我的Database固定為SQL Server那用DataSet、LINQ與EntityFramework資料存取技術有何差別?那一種比較好?LINQ操作不是都有支援嗎?

    2010年11月22日 上午 01:28

解答

  • 所有的純ORM都會有效能問題,因為ORM不單單只是封裝SQL而已,還有很多其他的功能.
    所以如果要用EF就免不了會有效能上的問題.
    但是很多效能問題在於設計上的問題,譬如說你提到的資料顯示問題,不論是用ADO.Net或是EF從資料庫撈取上萬筆資料來顯示都會有問題,最好的做法必須靠分頁.這類問題非常之多.
    我在很多問題都有回覆過,採用EF的前提示程式架構必須用OO思維來撰寫,如果程式本身還是程序式採用EF並不會帶來太多好處,大多是弊遠大於利.因為所有ORM的架構都是以OO為基礎來做設計,ORM的完整名稱是Object-relational mapping,從名稱可知,所餵ORM就是為了解決物件與關連式資料庫間的對應問題而生.
    如果是小程式或許使用EDM的拖拉工具可以快速開發程式,但實際上EF的目的不在於此,當程式架構越大時如果程式寫法還是程序式模式,會發現EF使用上的問題相當之多,最終的結論大多是架構設計上之問題,而非是EF產品本身.
    或許EF在與某些ORM比較之下效能會比較差,但ORM的功能通常遠比效能來得重要,只要效能能達到一個標的,就不是要考量的因素,就像以前常常會有人用C,Assembly來與VB或Delphi或Java,dotNet來做速度比較,或許可能會差距10倍甚至百倍之譜,但試想如果開發一個資料庫為導向的程式誰會選擇Assmebly?
    一樣的問題發生在ADO.Net與EF上,如果很注重效能,那ADO.Net還是比較好的選擇.

    Devart的EntityFramework工具主要是改善與增強原來的工具之不足(不然誰要買...),在現階段VS內建的EDM Tools Desinger不是很好用,如果使用到內建工具本身並沒有的功能,很抱歉必須手動編輯EDM file,這不要緊,重點是手動編輯後EDM Tools Desinger就失效了....也就是只要使用到內建工具本身並沒有的功能那就必須完全的手動編輯EDM File,為此之前我曾經將CSDL,MSL與 SSDL這些檔案花了很多時間搞懂它們,但也感謝因此我更了解EF內部的運作了..但是當使用越多時雖然我可以手動編輯這些檔案,但實在太花費時間,而且因為搞懂這些檔案並不容易,所以我也很難將工作交給他人,最後看到Devart的工具後我決定使用它了,到目前為止在現有的專案 Modeling部分沒有遇到Devart的工具無法處理的狀況.

    PS:
    另外還有一種半自動的ORM Solution在於兩者之間(用Google搜尋一下半自動ORM), 只是用得人不多供你參考.

    • 已標示為解答 Tony_Huang 2010年11月23日 上午 06:31
    2010年11月23日 上午 02:49

所有回覆

  • LINQ是一個基於dotNet的查詢語言架構,LINQ本身只是定義查詢方式,實際的資料來源可以是任何符合Linq結構的資料.
    目前微軟針對LINQ有出了

    1.LINQ to Object -> 泛指dotNet中的集合型態
    2.LINQ to XML -> 查詢XML
    3.LINQ to DataSet -> 查詢DataSet
    4.LINQ to SQL -> 查詢SQL
    5.EntityFramework -> 查詢資料庫

    EntityFramework與 LINQ to SQL類似,這兩者與DataSet的差異是前者是一種ORM,而後者只是擴充讓LINQ也可以查詢ADO.Net.
    至於哪種比較好要看你的選擇,沒有絕對,應該是先了解這些產品的差異後再來決定你要使用的技術.

    所以只要有能力也可以開發任何符合LINQ定義的查詢來源,譬如說你可以撰寫讓LINQ可以查詢檔案路徑,又或者也可以撰寫讓LINQ可以查詢WMI,取代WMI的Query.
    LINQ的目標是讓所有在dotNet中查詢的方式能夠有一種統一標準,譬如說WMI的查詢與法跟SQL或是XML的XPath三者是不同的語法,以往要針對這些資料來源做查詢必須學會各種查詢語法,透過Linq就可以簡單化只要會Linq即可.

    2010年11月22日 上午 02:13
  • 如果我們Database為Oracle那似乎只能選Type-DataSet,用LinQ to DataSet嗎?

    2010年11月22日 上午 03:01
  • 不,
    Entity Framework也可以支援任何符合Entity Framework標準的資料來源.
    目前新的Oracle dotnet connector已經支援Entity Framework,My SQL也有.
    不過EDM tools可能會有些問題.但這個問題很好解決,已有廠商提供解決方案.

     

    2010年11月22日 上午 03:20
  • 可是Oracle官方網站說目前不支援LINQ & EntityFramework要明年才會出驅動程式支援!

     

    Oracle 11g Release 2 ODAC 11.2.0.1.2 with Oracle Developer Tools for Visual Studio

     Download the File:
     

    ODAC 11.2.0.1.2 with Oracle Developer Tools for Visual Studio

        - Includes support for Microsoft Visual Studio 2010 and .NET Framework 4
         
       

    Download Includes

       Oracle Developer Tools for Visual Studio 11.2.0.1.2
       Oracle Data Provider for .NET 4 11.2.0.1.2
       Oracle Data Provider for .NET 2.0 11.2.0.1.2
       Oracle Providers for ASP.NET 4 11.2.0.1.2
       Oracle Providers for ASP.NET 2.0 11.2.0.1.2
       Oracle Database Extensions for .NET 4 11.2.0.1.2 -- for upgrade only
       Oracle Database Extensions for .NET 2.0 11.2.0.1.2 -- for upgrade only
       Oracle Provider for OLE DB 11.2.0.1.0
       Oracle Objects for OLE 11.2.0.1.0
       Oracle Services for Microsoft Transaction Server 11.2.0.1.0
       Oracle ODBC Driver 11.2.0.1.0
       Oracle SQL*Plus 11.2.0.1.0
       Oracle Instant Client 11.2.0.1.0

    2010年11月22日 上午 03:26
  • 抱歉,那應該是我記錯了.
    不過有個解決方案
    http://www.devart.com/dotconnect/oracle/overview1.html

    這間公司專門做.net的資料存取元件,我的Entity Framework MySQL是採用這家公司的產品,而未使用MySQL本身.
    因為有個很重要的原因,dotNet內建的設計工具無法100%包容所有Entity Framework的功能,所以如果在使用時有用到工具未提供的,那就必須完全捨棄工具採用人工編輯(這是個很高的門檻).而這家公司產品幾乎100%包含.

    2010年11月22日 上午 04:00
  • 請問我看先前討論說Entity Framework會有效能不彰的問題,ORM的優點來自於隱藏SQL語句及物件呈現上,那有何條件讓我們非選Entity Framework技術來開發Models,我們資料庫有些Table資料筆數達數十萬筆,如果交由Entity Framework幫我們產生SQL,User對於效能可能不能接受;比如說網頁要做料號選取也要處理分頁呈現,很怕程式一次就撈數十萬筆資料!可否分享你們使用Devart的EntityFramework使用經驗?非常感謝!
    2010年11月23日 上午 02:26
  • 所有的純ORM都會有效能問題,因為ORM不單單只是封裝SQL而已,還有很多其他的功能.
    所以如果要用EF就免不了會有效能上的問題.
    但是很多效能問題在於設計上的問題,譬如說你提到的資料顯示問題,不論是用ADO.Net或是EF從資料庫撈取上萬筆資料來顯示都會有問題,最好的做法必須靠分頁.這類問題非常之多.
    我在很多問題都有回覆過,採用EF的前提示程式架構必須用OO思維來撰寫,如果程式本身還是程序式採用EF並不會帶來太多好處,大多是弊遠大於利.因為所有ORM的架構都是以OO為基礎來做設計,ORM的完整名稱是Object-relational mapping,從名稱可知,所餵ORM就是為了解決物件與關連式資料庫間的對應問題而生.
    如果是小程式或許使用EDM的拖拉工具可以快速開發程式,但實際上EF的目的不在於此,當程式架構越大時如果程式寫法還是程序式模式,會發現EF使用上的問題相當之多,最終的結論大多是架構設計上之問題,而非是EF產品本身.
    或許EF在與某些ORM比較之下效能會比較差,但ORM的功能通常遠比效能來得重要,只要效能能達到一個標的,就不是要考量的因素,就像以前常常會有人用C,Assembly來與VB或Delphi或Java,dotNet來做速度比較,或許可能會差距10倍甚至百倍之譜,但試想如果開發一個資料庫為導向的程式誰會選擇Assmebly?
    一樣的問題發生在ADO.Net與EF上,如果很注重效能,那ADO.Net還是比較好的選擇.

    Devart的EntityFramework工具主要是改善與增強原來的工具之不足(不然誰要買...),在現階段VS內建的EDM Tools Desinger不是很好用,如果使用到內建工具本身並沒有的功能,很抱歉必須手動編輯EDM file,這不要緊,重點是手動編輯後EDM Tools Desinger就失效了....也就是只要使用到內建工具本身並沒有的功能那就必須完全的手動編輯EDM File,為此之前我曾經將CSDL,MSL與 SSDL這些檔案花了很多時間搞懂它們,但也感謝因此我更了解EF內部的運作了..但是當使用越多時雖然我可以手動編輯這些檔案,但實在太花費時間,而且因為搞懂這些檔案並不容易,所以我也很難將工作交給他人,最後看到Devart的工具後我決定使用它了,到目前為止在現有的專案 Modeling部分沒有遇到Devart的工具無法處理的狀況.

    PS:
    另外還有一種半自動的ORM Solution在於兩者之間(用Google搜尋一下半自動ORM), 只是用得人不多供你參考.

    • 已標示為解答 Tony_Huang 2010年11月23日 上午 06:31
    2010年11月23日 上午 02:49