以前寫資料層D層的時候裡面有好多的SQL語句，如何省略到繁瑣的SQL語句，微軟提供了一種很好的方式-實體架構-Entity Framwork。一種對象映射機制，支援.NET開發人員使用域特定對象來出來關系資料，消除了對開發人員通常需要編寫的大部分資料通路代碼的需求。
ADO.NET Entity Framework 是微軟以 ADO.NET 為基礎所發展出來的對象關系對應 (O/R Mapping) 解決方案。實體架構Entity Framework是ADO.NET中的一組支援開發面向資料的軟體應用程式的技術。是微軟的一個ORM架構。
什麼是ORM架構？廣義上指的是面向對象的對象模型和關系模型資料庫的資料結構之間的互相轉換。狹義上，可以被認為，基于關系型資料庫的資料存儲，實作一個虛拟的面向對象的資料通路接口。理想情況下，基于這樣一個面向對象的接口，持久化一個OO對象應該不需要了解任何關系型資料庫存儲資料的實作細節。如下圖：O(對象模型)-M(映射關系)-R（關系模型）。
Find out about the different ways you can use Entity Framework to access a relational database from your .NET application.
實體架構的三種實作方式：即ModelFirst ，DBFirst ，CodeFirst。
ModelFirst通過已有的實體類圖轉換生成sql腳本，建立資料庫。DBfirst根據已有的資料庫映射出對象的實體類。CodeFirst根據已有的實體類的代碼生成SQL腳本，建立資料庫，支援跨資料庫。具體的搭建過程不再贅述。
衆說EF優缺點：
貼一：
改變在現有系統使用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産生查詢，他們是難以維護的，它并不能很好地支援映射到不規範的表。
• 對程式有非常的性能要求, 需要對每個查詢進行監控.
摘自:http://www.cnblogs.com/wintersun/archive/2013/03/16/2963992.html
貼二：
Entity Framework是M$提供的一個ORM架構，它旨在為小型應用程式中資料層的快速開發提供便利。
nuget上185W多的下載下傳量，說明.Net開發人員還是比較喜歡用EF的。但是EF在提供了便利性的同時也有許多缺點，以下就是我認為不應該應用EF的場景：
- 非SQL Server資料庫且無該資料庫的DataProvider
- 高性能要求。在進行一些複雜查詢的情況下，EF的性能表現不太好，而開發人員又無法控制SQL語句的生成
- 高安全性要求。有時候DB使用者僅僅具有EXEC的權限，而EF自動生成的類又不好用，還是需要自己來寫
ps: 看了很多關于它的評價，坦然講，這裡不免有 拒絕的聲音。這可是微軟關于資料處理的一大進步。小編還是先接受并深入了解後再做定義吧。存在即是合理。