ADO.NET Entity Framework 在哪些场景下使用？

　　Enity Framework已经是.NET下最主要的ORM了。而ORM从一个Mapping的概念开始，到现在已经得到了一定的升华，特别是EF等对ORM框架面向对象能力的升华。切实地说，就是ORM让数据库在整个应用过程中更好地被封装和抽象化。

　　ORM一开始只是Mapping，最基础的就是表与类的对应、Column和属性的对应，这只是最基础的。在这个层次上，数据库对象通过Mapping在面向对象语言层面，也就是业务层面被封装成了业务对象，然后允许以操作业务对象的方式对数据库进行操作。

　　但是，在很长时间里，ORM的提升都被对象与关系间的“阻抗失配”困扰。一直以来很多ORM的水平都只是维持在了用对象的方式进行CRUD而已，除了减少代码错误、提高简单查询的开发效率，在复杂查询、性能等等一些方面结果都还是要跨层回到底层的操作框架比如ADO.NET甚至存储过程去解决问题。

　　所以，在应用场景上来说简单查询的场景EF和其他ORM都是能够胜任的。

　　从应用场景说起，这点在B/S和C/S里也会很明显。用户使用Web的时候和使用桌面软件的最大体验不同是什么?——所见即所得。你在网页上操作了半天，一个关闭就全没了，还必须提交然后获得下一个页面才能把数据状态和UI更新;而同样在桌面上，你的操作比如画图，在操作的一瞬间结果就出来了。当然了，Web 2.0技术就在解决这个问题。

　　同样在OO和RDBMS中的问题也在这里。

　　从OO的角度上看，你运行下一段代码结果如何：

　　user.Name = "Indream Luo";

　　在OO里，就是user对象的Name属性被更新了。如果是一个桌面软件，那么用户的名称应该也更改了。

　　但是如果这个对象的数据是存在关系数据库中，或者任意数据库，那么结果都逃脱不出这个套路：

　　var object = db.Get(id);

　　change(ref object);

　　db.Update();

　　你需要把更新Push过去，将操作和数据持久化。

　　在存储分层开始，推送更新就不可避免，哪怕在说面应用中，也是将对象的更新推送到了UI。ORM站立在应用场景不一致中间所要扮演的角色，就是一个润滑剂的角色。

　　在我所能马上想起的特性，就是EF和NHibernate的缓存机制。EF是一级缓存，NH是二级缓存，手动的话似乎EF也可以做到二级。然后在.NET下最重要的一点是有LINQ。LINQ在有合适的Provider的情形下可以把OO的序列化操作转化成目标的序列化操作，在这里就是LINQ转SQL，这样就省去了拼接SQL、SQL注入等很多麻烦。另外LINQ延迟加载的特性也很大地减少了用户控制SQL执行的工作。