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

ADO.NET Entity Framework，我习惯性地称呼它为 EF，在我看来，它就像是一座桥梁，一座将我们熟悉的面向对象的世界与数据库这个关系型世界连接起来的桥梁。它不是那种能让你在一夜之间成为数据库专家的工具，也不是让你对 SQL 语法烂熟于心才能使用的东西。相反，它更像是为那些专注于业务逻辑、希望以更“对象化”的方式与数据打交道的人们准备的。

我第一次真正体会到 EF 的威力，是在一个需要频繁与数据库进行数据交互的项目里。当时的团队，大家都很熟悉 C，但对 SQL 的掌握程度参差不齐。每次涉及到增删改查，都要写大量的 SQL 语句，然后还要手动将查询结果映射到 C 对象上，这其中涉及的重复劳动和潜在的错误实在是太多了。

引入 EF 之后，一切都变得不一样了。我不再需要绞尽脑汁去写那些复杂的 JOIN 语句，也不必担心 SQL 注入的风险。我只需要定义好我的 C 类，它们就成为了我数据库中表的“映射”。例如，我有一个 `Customer` 类，里面有 `Id`、`Name`、`Email` 等属性，EF 就能很聪明地知道，这对应着数据库里一个名为 `Customers` 的表，并且其中的属性与表中的列一一对应。

然后，我要查找所有活跃的客户，我不再需要写 `SELECT FROM Customers WHERE IsActive = 1` 这样的 SQL。取而代之的是，我可以用 C 的 LINQ（Language Integrated Query）语法来表达：`context.Customers.Where(c => c.IsActive == true).ToList()`。你看，这多么直观！就像在操作内存中的对象一样。`context` 这个对象，就是 EF 提供的一个“数据库会话”的入口，我通过它来访问和操作我的数据。

EF 的另一个让我印象深刻的方面是它的“迁移”功能。想象一下，当你的应用程序需要更新数据库结构的时候，比如添加一个新字段，或者修改一个字段的类型。如果没有 EF，你可能需要手动编写 ALTER TABLE 语句，然后小心翼翼地在生产环境中执行，这简直就是一场冒险。

但有了 EF 的迁移，我可以先在我的 C 模型中进行修改，比如给 `Customer` 类添加一个 `PhoneNumber` 属性。然后，EF 就能自动生成一个 SQL 脚本，记录下从旧数据库结构到新结构的这个改变。我只需要运行这个脚本，数据库结构就更新了。而且，EF 还能跟踪这些迁移的历史，让你知道数据库经历了哪些变化。这对于团队协作，尤其是多人开发时，简直是福音。

此外，EF 也支持不同的“模型优先”和“数据库优先”的策略。

模型优先：这是我上面提到的那种，我先在 C 中定义我的领域模型，然后 EF 根据这个模型生成数据库结构（如果数据库不存在的话）或者生成迁移脚本来更新数据库。这种方式非常适合从零开始开发新项目，或者对领域模型有非常清晰定义的情况。它强调的是用代码来驱动数据库的设计。

数据库优先：有时候，我们接手的项目已经有一个现成的数据库，而且这个数据库结构可能非常复杂，甚至是历史遗留的。在这种情况下，EF 也能派上用场。我可以通过 EF 的工具，根据现有的数据库结构生成 C 的实体类和 `DbContext`。这样，我就可以继续使用 LINQ 来操作这个已有的数据库，而无需修改数据库本身。这让 EF 能够适应更多实际的工作场景，而不只是局限于新建项目。

当然，EF 也不是万能的。对于一些特别复杂的、需要极致性能调优的 SQL 操作，或者需要直接利用数据库特有的功能时，我可能还是会选择直接编写 SQL。但总的来说，在绝大多数需要与关系型数据库进行数据交互的场景下，EF 提供了一种更现代化、更高效、也更符合面向对象编程思想的解决方案。它让数据访问层不再是乏味的 SQL 堆砌，而是成为了一个充满生命力的、响应业务需求的变化而演进的部分。

首先我对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不是一个好的选择。