EntityFramework優缺點

2015-12-9 14:39:22 次瀏覽 分類:軟件開發

改變在現有系統使用EntityFramework的優勢是什么?


? All -in-1框架的類映射表,需要編寫映射代碼, 并且是很難維護的。 
? 可維護性,易于理解的代碼,無需創造大的數據訪問層。 
? 提供LINQ查詢數據庫,這需要從初級開發人員不太了解SQL。 
? EF可以用作用于數據服務和OData Service的基礎設施。

什么的情況下,不建議使用EF呢?


? 實時的應用程序。 
? 只能通過存儲過程訪問數據庫。 EF的優勢是:跟蹤實體狀態Change時,不僅僅在存儲過程上.(即使EF確實對存儲過程支持有限的)。 
? 頻繁插入操作(Insert),  并且EF不支持大數據Bulk 插入。 
? 頻繁更新操作,更新的目標主要是當多行(用一個單值) 
   例如:UPDATE 表名 SET ColumA = 10 Where ColumnB =? 
   這種更新操作更好的使用的ExecuteNonQuery(也可從Context上下文或直接從Ado.Net)。 
? 反范式的表設計和高性能查詢。 EF產生查詢,他們是難以維護的,它并不能很好地支持映射到不規范的表。

? 對程序有非常的性能要求, 需要對每個查詢進行監控.

 

我們要在加載所有數據到內存中,建議使用實體框架? 我們應該期待什么樣的問題呢?


? 加載的所有實體將需要許多查詢和大量的時間。 
? 內存開銷。 
? 會有延遲,因為EF需要跟蹤實體的變化的和大Collection對象的處理。 
? EF的Context上下文不是線程安全的,你不應該在整個Service上使用一個Context上下文。 
? 如果你打算這樣做,使用EF加載實體,但并不管理它們. (Detach the entities從context)。 
? 不使用的上下文Context對象作為一個緩存對象(用于分布式的情況下).   它不是線程安全的,有一些開支和不遵循分散關注(Separation of Concern)的設計。 更好的辦法是設計緩存API,如AppFabric緩存。

 

技術層面:

內存泄漏:

我們有這樣一個場景,每10秒我們打開Context上下文獲取一個單表,并關閉它。 “using (entities context = new entities(_connection)) {… ”

經過一段幾個小時,這引起了內存泄漏。 
? 我建議你檢查內存泄漏,以確保它是從EF是根源。 EF是一個開源的,所以現在可以報告任何內存泄漏并修正它。 
? 使用Profiler的VMMap,以便跟蹤泄漏的源頭。

在這種情況下,我們應該保持Context一直打開?


? 這其實并不重要,因為查詢仍然會執行。 然而,這是最好關閉Context下,所以緩存的實體將垃圾回收,否則Context和緩存的實體將在GC中升級到第二代,并且會被困在那里的持續一段時間。 
? 不要為WCF每個請求創建一個Context上下文對象。 
? 推薦的做法是為每次操作創建的Context對象,因為實體Item一旦被被添加到數據庫后就已經過時了,可能會導致數據損壞或重復的Item

 

EDMX的大小有影響嗎?


? EDMX影響的大小,因為所有的EDMX數據加載到內存中創建Context上下文。 
? EDMX被加載到內存中,解析與映射在AppDomain中創建和緩存。 您可以關閉并重新打開Context,它沒有影響已緩存EDMX映射。

 

非常多的表

如果所有的表放在單個的EDMX或分別存放于幾個EDMX文件之間?

如何能管理的EDMX中大量的實體? 例如,如何可以找到它們?

在設計器中修改一個特定的表? 

? 如果拆分之間edmx文件,你可以不連接實體的導航性能。 
  你應該建立自己的模型,根據您的實體模型設計 - 如果你有一組是獨立的實體,他們可以在不同的EDMX模型。 
   EDMX文件處理數百個實體類型。 如果實體類型的數量超過1000家,我會考慮到的幾個Edmxs(分開和重新審視自己的實體模型設計,因為成千上萬的實體類型的一個系統似乎太多)。 
? 在VS 2012,以設計器的增強分解功能和著色等,請參閱以下鏈接 
? EF設計器有一些改進,如著色區分實體組的實體。 
   也有第三方實體的設計器,可能會得到更好的用戶體驗。 
   請記住 - EF是一個開源的,你可以給他們的要求,甚至貢獻自己的增加,所以在EDMX設計器探索很有趣的。 
? 你應該按每個域/服務來拆分edmx文件到不同EDMX文件。

 

表之間關系 
 

Lazy與No Lazy模式? 
? 在分布式情況下Lazy代碼是魔鬼。 
? 如果他們需要一組表中的數據,然后使用Include,否則,你可以使用Lazy Load模式

 

“Include”命令加載整個表或ObjectSet原始記錄? 
? Include加載是相關實體的列。 EF不使用 * 查詢.

 

如何使用EF執行批量插入/更新操作? 
? 做不到這一點,你需要使用原始的SQL語句來實現。

 

當一個實體被標記為已修改,EF更新的所有列? 
? 它不更新所有的列,除非你正在使用分布式的應用程序與Self-Tracking。 “正常”實現下EF只更新修改列。 Self-Tracking不跟蹤的已更新的屬性,它標志著的所有屬性已更新。 您可以編輯Self-Tracking,并修復它,如果需要的話。 
? 您可以附加一個SP以實現自定義的邏輯。 
? 您可以更改T4模板的文件,在Self-Tracking下以保持所有原始值。

 

整個RAW更新的開銷大么? 
? 大多數DB重新計算索引。 這是一個問題關系到DBA。 

 

當我們使用EF為700-800KB的XML文件來更新XML列,我們收到了有關SQL Server的tempdb一個異常。 什么造成的嗎? 
? 可能涉及到數據庫如何用臨時表來更新XML的內容。

   應該和DBA檢查你的數據庫,你也許需要增加您的tempdb數據庫的大小。 
? 在一般情況下, 大的對象,如XML使在GC的Large Object Heap內存的壓力,你應該考慮遷移到.NET 4.5版本的GC大型對象堆碎片整理特性。 
? 你可以考慮來存儲XML為byte [],它可以被壓縮(XML不是一種非常經濟的格式)。

 

使用EF與ADO.Net的開銷? 
? DataReader的結果變換到對象的開銷,從LINQ編譯SQL查詢的開銷。

   您將有相同的開銷,甚至更多,如果您嘗試建立你自己的ORM框架。 不這樣做! 
? 抽象層的開銷, 它取決于他們用EF所做的事情。 
? 一般而言,您應該組合替代繼承,避免它有一個更大的開銷。

推薦知識

  • 軟件開發流程

    軟件開發流程需求分析1.相關系統分析員向用戶初步了解需求,然后用word列出要開發的系統的大功能模塊,每個大功能模塊有哪些小功能模塊,對于有些需求比較明確相關的界面時,在這一步里面可以初步定義好少量的界面。2.系統分析員深入了解和分析需求,根據自己的經驗和需求用WO…

    2015-7-23 9:46:42
  • 定制軟件的四大優點

    定制軟件在很多時候不僅是必要的,而且是必須的。所以深入了解一些定制軟件方面的知識對于每個公司的決策層來說是非常有必要的。通常大家認為定制軟件的優點主要體現在以下幾個方面:1.針對性強 定制軟件因為是量身定做的,所以針對性非常強,這也是定制軟件最大的優點。因為每…

    2015-7-22 9:34:26
  • 軟件開發需要學習什么

    一、重視基礎課的學習,計算機雖然是高科技的象征,但又受到其它專業發展的制約。二、理論聯系實踐,學習編寫程序,不僅要領悟老師的各種知識點,多看教材,還要結合課程重視上機的練習。

    2014-11-17 9:47:39
  • 面向對象編程思想,面向對象的世界觀

    它是從現實世界中客觀存在的事物(即對象)出發來構造軟件系統,并在系統構造中盡可能運用人 類的自然思維方式,強調直接以問題域(現實世界)中的事物為中心來思考問題,認識問題,并根據這些事物的本質特點,把它們抽象地表示為系統中的對象,作為 系統的基本構成單位(而不…

    2014-11-6 10:58:43
掌上英雄联盟 足彩胜负对阵表 qq游戏陕西麻将外挂 今天内蒙古快3开奖结果 北京十一选五开奖85期 中华彩票首页 大赢家足球比分直播 时时彩前三稳赚方法 注册试玩赚钱 新疆25选7中奖程序 新疆时时彩开奖结果四 内蒙古快3开奖走势图今天 彩经网APP 内蒙古时时彩计划软件下载 河北福彩排列7走势图 棋牌麻将玩法 2012上证指数数据