以前写数据层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: 看了很多关于它的评价，坦然讲，这里不免有拒绝的声音。这可是微软关于数据处理的一大进步。小编还是先接受并深入了解后再做定义吧。存在即是合理。