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

首先我对EF没啥好感，因为两次将EF纳入开发框架内的尝试都失败了。

当然，我最后接触的EF版本是EF 5，更新的版本也许解决了一些问题，所以我说的不一定对。

首先来看问题：

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

事实上EF的设计上来说还算是一个百搭的框架，而且是功能最为强大的ORM框架，可以说如果你不需要对数据库进行精确地控制，那么基本上EF都是适用的。但适用不代表好用，要真正把EF玩好，恐怕比想象中的难。

当我写一个简单的网站的DEMO的时候，EF可以帮助我快速的构建数据访问，我也有能力在这个基础上扩展为大型架构。但是当我尝试将EF纳入数据库访问解决方案的时候，我发现了这个东西的很多不足。

其实这也是绝大多数ORM框架的不足，而EF的一个麻烦之处在于，这货过于强大，强大到程序员根本意识不到自己在做一件非常愚蠢的事情。或者通过这些实践我意识到ORM根本不适合快速构建。

没错，你没看错，其实使用ORM框架对于快速构建是起到负面作用的。这与一般人的感知不同，一般人会认为ORM解决了大量的问题，将复杂的数据逻辑封装在强类型的容器之下，我们只需要假装所有数据都在内存里，使用熟悉的LINQ或者扩展方法挑选想要的数据即可，大大的降低了开发难度和提升开发效率。

但我的实践中发现事实并非如此。

其中一个严重的问题在于，EF的工具链如此完备，以致程序员滥用自动产生的实体类型。一个让人抓狂的事情就出现了，他们总是获取表的所有字段，而意识不到这在很多时候其实是一个灾难。

更抓狂的是他们会把相关的所有表的字段一起取出来（Include）。

这显然不是我们想要的，但准确的说，这不是EF的错。为了达到性能和方便的平衡，我们应当针对每一种情况设计专用的数据实体并进行映射，这样，EF就只会获取最必须的字段而非全部。

但这样一来，系统内的实体类爆炸式的增长，而初级程序员们根本不具备如何设计一个合格的数据实体的能力，在抽象和取舍方面总会做出各种让人抓狂的选择。最终你不得不亲自或者指派资深程序员专门来设计这些实体对象。这种额外的工作量大大的抵消了EF带来的好处。

最后你会发现EF的体系其实比较封闭，至少在EF5的时候仍然是这样，仅仅是监控SQL执行情况这样简单的需求，你需要重写很大一片的代码，深入到EF内核中处理各种你根本不必要了解的细节。

所以就我的经验来说，EF，或者说所有的ORM框架，其最适合的场景是稳定的业务系统，企业应用开发。如果有完整和稳定的领域建模和数据建模，那么不论是用CodeFirst或是其他什么方式构建数据模型，用EF来访问数据库，会是一个不错的体验。

而如果你的数据建模不稳定，没有专职的人员负责的话（简单说互联网领域大都这样），ORM不是一个好的选择。