ADO.NET Entity Framework的目标是，让程序员尽量少去应用SQL语句与数据层交互，这种思想是很好的。因为程序员们更擅长的是用语言，框架实现业务逻辑，当然，也有很多程序员是通SQL语法的。当然，DBA们也是不擅长去写代码的，特别是业务逻辑的操作。其实不擅长还好说，因为可以学习，可以练习，然后达到擅长。但更重要的一点，就是延长了开发周期，增加了开发成本，这个是管理者不希望的。

为了解决程序员和DBA的工作，有很多好的想法，架构诞生，三方的很多，看一下微软的解决方案吧。

.NET出现后，就带着ADO.NET，ADO.NET是最原始的数据操作方式，虽然相比以前的数据连接方式来说，微软把数据连接，数据命令，以及数据集合都封装成对象，这在一定程度上已经让程序员操作数据库时得到了简化，但在操作数据库时，还是要写很多的SQL语句的，并且这些语的语法验证，只有在把这个语句送到数据库上去执行时，才执行，这种情况还加大了调试的难度。

在.net的第四个版本，即visual studio 2008中，引进来一种新的操作数据的技术，LINQ to SQL，通过向导，可以把数据的结构引入到程中，并且能完成数据库与对象，表与对象，字段与属性的对应，并且也能很好的解决存储过程，自定义函数与c#中方法的对应关系。虽然LINQ to SQL能帮程序员避免SQL语句，也能提高开发效率，但LINQ to SQL这个从数据库到实体类的映射是很死板的，很直接的，只是简单把表和实体类作了一一对应，没有真正的分析数据表之间的关系，作进一步的处理。另外一点，数据表结构与实体类结构的对应关系是固定的，但数据表数与实体对象就不是一一对应了，其实是一行数据，对应一个实体对象，也就是数据库表实际上是对应实体类的一个集合对象，这点在LINQ to SQL中也是没有很好的处理，因为直接映射，所以表名与实体名相同，所以对程序员来说，这个命名有点奇怪。

ADO.NET Entity Framework(以下简单EF)在visual studio2010中出现了，它很好的解决了LINQ to SQL不能解决的问题，他在从数据库映射实体类时作了分析，比如，如果两张表是多对多的关系，在EF中的视图中，是看不到多对多的这张表的，如下图：

 

（数据库的E-R图）

 

（EF中的实体关系图）

数库与实体间的映身，其实微软是通过一个 XML格式的配置文件存储起来的，格式如下图：

 

SSDL节是存储数据库端信息

CSDL节是存储实体端信息

C-S数据库与实体映射信息

下面的其他节点是关于生成视图后，EF各图布局及呈现。

关于实体的字称与数据表名的对应关于，我们看到，数据库表名是Users，Roles，Permissions，但实体都没有带有s，因为一个实体只表示数据表中的一行记录，这个转换是通过属性来设置的，如下图：

 

实体名称为User，实体的集合名称是Users。

对于数据库的操作，EF实现了基础的操作，但不是所有的DCL和DDL能完成的操作都能完成，比如对直接删除符合条件的数据，如果用EF去解决的话，实体没有提供这个功能，只能自己定存储过程，来完成，当然，对于数据的操作了，为了性能的优化，也***是通过存储过程和自定义函数来完成操作。

对于其他数据的支持，微软没有提供，仅提供了对SQL Server的框架，当然我们可以建立在其他数据的Provider上去构建自己的EF也是可以的，参照SQL Server的架构来实现，也能达到这个效果。