Code First is a bad name，这些年咱们对Code First的理解都错了 ！很震惊吧？

　　当看到这个时，我也很震惊。估计绝大多数的人和我同样，这些年来，一直不知道Code Fisrt的真实意义。下面是一篇讲述此状况的译文，欢迎围观，如有翻译不当的地方，请指正，谢谢。若是被惊到了，请点赞！，不满意就拍砖吧。E文好的，可直接看下边的原文。

原文地址：http://blogs.msdn.com/b/adonet/archive/2014/10/21/ef7-what-does-code-first-only-really-mean.aspx

转载请注明出处：http://www.cnblogs.com/VolcanoCloud/p/4483708.html

　　进入主题以前，我先说一下，我听来的。听说微软最开始想使用的是 Code Only，后来因为他们的营销团队不知道是为了跟Database First 、Model First 对应仍是怎么的，就出现了如今的 Code First.

EF7-"Code First only"的真实意思究竟是什么？

　　不久前，咱们在博客中写到，咱们计划将EF7打形成一个轻量级的、可扩展的版本。它将是一个全新的平台和数据存储（data stores)。咱们在北美技术大会（TechEd North America)关于EF的会议中，一样有说起EF7的计划。

　　在EF7以前，存储（译注：这里当动词用）模型有两种方式，一种是基于XML的EDMX文件格式，一种是基于代码。从EF7开始，咱们将再也不支持EDMX格式，转而只支持单一的基于代码风格的存储。对于移除对基于XML的EDMX这事，引发不少人的担心，他们中间，多部分人是源于对“EF7 将只支持Code First“真正含义的误解。

Code First 是一个糟糕的名字

　　在EF4.1以前，咱们只支持Database First和Model First两种工做方式，它他均使用EF设计器提供的方框和直线来表示存储在基于xml格式的.edmx文件中的模型。Database First 从一个已存在的数据库逆向生成一个模型，Model First从EF设计器中建立的模型生成数据库。

　　在EF4.1中咱们引入了Code First. 不幸的是，不少人依据它的名字认为，它是在代码定义模型，而后从模型生在数据库， 事实上，Code First 一样也能用于一个已经存在的数据库或者是生成一个新的数据库。有工具能够支持逆向一个已存在的数据库生成Code First模型，这个工具最初是包含是EF工具集中，后来在EF6.1中被集成到生成EDMX模型的向导中。

　　换句话来讲，Code First 不是相对 Database First 和Dodel First的第三种方式，而是一种能够替代EDMX文件格式的方案。从概念上讲，Code First 同时支持Database First和Model First工做方式。

　　这的确让人感到混乱，咱们取错了名字。 或许叫它“基于代码建模（code-base modeling）”会更清晰些。

 

是否是使用基于代码建模（code-base modeling）这个名字就更好的呢？

　　很明显，咱们得维护两种不一样的建模方式。除此以外，还有别的缘由让咱们选择在EF7中只支持基于代码建模（code-base modeling）的方式。

 

　　　　一、 源代码控制合并、冲突、代码审审变得困难。当把整个模型存储在一个xml文件时，咱们收到了不少开发人员的反馈，模型上一个简单的改动，　　　　 将致使xml中产生较大的差别。别一方面，开员人员得合并和从新审查源代码。

 

　　　　二、 开发人员知道如何编写和调试代码。在一些简单的项目中，设计器无能否认的带来便利。然而，不少项目的需求却超了出了设计器的能力范围。遇到这种状况时，须要修改xml文件里的一些东西，但这对多数开发人员来讲，这比修改代码要艰难不少。

 

　　　　三、 根据环境自定义模型的能力。咱们从客户那里听到这是一个很广泛的需求，好比，在程序运行时你须要指定架构或是表前缀的多租户数据库（Multi-tenant database）。也在可能会根据不一样的数据库提供商在运行时轻微调整你的模型。实现这些需求，使用操做基于xml文件的模型会异常艰难。另外一方面，在代码中使用条件逻辑来定义模型会很容易实现 。

 

 　　　　四、基于代码的模型不会重复。由于CLR类型一样也能构建模型，以及有照顾通常配置（take care of common configration)的约定。 假设一个Blog实体拥有一个BlogId主键。在基于EDMX的模型中，在CLR类中会有一个BlogId属性，一个xml BlogId属性（外加列和映射）以及另外的一些xml内容来标识BlogId做为一个实体键。但在基于代码的模型中，拥有一个CLR类型中的BlogId属性就够了。

 

　　　　五、在代码中提供有用的错误信息更容易。咱们都见过”Error 3002: Problem in mapping fragmets starting at line 46...(3002:映射段问题，始于文件46行处...）的错误。这个来自基于EDMX模型报告应该被改进。可是在基于代码的模型中抛出一个配置错误的异常会很容易。

　　咱们可能已注意到，在EF6.x版本，常常会从代码优先管道（Code-First pipeline)中得不到有用的错误信息，这是由于它是创建在为EDMX模型设计的基础设施上。在EF7中，将不会存在这样的状况了。

 

　　还有一很重要的功能，可能会被EDMX实现，但这只能在基于代码的模型了。

　　数据库迁移（Migrations) ,它容许你从基于代码的模型建立数据库，并随着模型的改变而演进。对于EDMX模型，你能够生成一个与当模型匹配的SQL脚原本建立数据库，可是没有办法生成一个包含模型变化的脚本，将模型变化应用于已存在的数据库。

 

那么，EF7会带来什么呢？

　　在EF7中，全部的模型均经过代码来表示了。有工具能够从一个已存在数据库逆向生成一个模型（像在EF6.x中那样），你也能够先经过代构建一个模型，而后使用数据库迁移(migrations）技术生成数据库（当模型发生变化时获得更新）。

　　可能已经注意到，咱们在EF7中已经改进了数据库迁移（migrations）技术，解决不少人在团队环境中使用它时所遇到的问题。

 

怎么解决...

　　咱们已经讨论了全部能想到的，选择只支持基于代码建模（code-based modeling)是一个正解选择的缘由。但随之而来的问题产生了。

 

怎么可视化模型？

　　EF设计器全是关于模型可视化，同时在EF6.x中，咱们有能力为基于代码的模型产生一个只读的可视化模型（使用EF工具集）.在EF7中咱们一样认为这是一个好的方法。可视化是绝对有价值的，特别是当你有大量的相联的类时。

　　Roslyn（微软推出的一种编译器）的到来，咱们也能够看到拥有一个可读可写的、基于代码模型的计设器。很显然，这不是立马就实现（多是永远），由于这是一个巨大的工做。但他是咱们努力的目标。

 

怎么解决“从数据库更新模型”场景？

　　“从数据库更新模型”是这样的一个过程，它容许你当即拉入一个附加的数据库对象（或是修改一个已存在数据库对象）到你的EDMX模型。不幸的是，这个实现，不是一个好的特性。由于你一般会所以丧失了自义定模型的能力，不得不手工去修改xml文件来调整模型。

　　对于Code First 你能够经过从新运行逆向工程进程，从新生成你的模型，在一些基本的场景中，这种方法表现得很好。可是你关心的是，新生成的代码会覆盖你在模型中自定义部分。不少的自定义，若是不经过修改搭建的代码，将很难适用。

　　咱们在EF7中第一步是，提供一个跟EF6.x中第一次发行的逆向工具同样的工具。在不用重写以前自定义的代码的状况下实现模型的增量更新上面，咱们有很多的想法。 从支持简单的添加场景到使用Roslyn编译器修改已存在代码。 咱们正在思考这些想法，目前尚未确切的计划。

 

怎么解决已经存在的模型？

　　咱们不掩饰EF7相对EF6.x所发生的巨大改变，虽然咱们保持原有的概念和顶层API,可是底层实现发生了巨大的变化。基于这个缘由，咱们不建议立马就将已存在模型转移到EF7中来，咱们将继续保持开发EF6.x一段时间。

　　

全部的人都须要改变吗？

　　咱们不自欺人，不可能让全部的人都改变，咱们知道有一些人对EF设计器和EDMX的喜好超过了基于代码建模。

　　与此同时，咱们必须平衡时间和资源，咱们会分享咱们认识最好的特性和功能来帮助开发人员编写一个成功的应用。 这并非咱们轻率，由于对于实体框架的长期发展和用户来讲，这是最好的选择。最终的目标是提供一个更快速的、更简单的使用栈，以及减小支持高需求的成本。咱们一直朝着这样方向努力。

 

　　翻译中，确定有不少不当的地方，恳请你的指正，同时，请点击下边的推荐来支持。谢谢！但愿你有收获。

 

　　下面是另外一篇MSDN的博客，是中文的，你们也能够去看看，原文地址：https://msdn.microsoft.com/zh-cn/magazine/dn890367.aspx。我摘抄一段我认为对你们有帮助的片断以下：

放弃 EDMX，但继续实行数据库优先

　　实体框架当前使用两种方法来描述模型。一种使用设计器中的 EDMX；另外一种涉及类，即代码优先 API 使用的 DbContext 和映射。若是您使用的是 EDMX 和设计器，则运行时 EF 会在 EDMX 后从 XML 中建立内存中模型。若是您选择代码优先路径，则 EF 会经过读取类（即您提供的 DbContext 和映射）来建立相同的内存中模型。从那之后 EF 的工做方式是相同的，不管您如何描述模型。请注意，经过 EDMX/设计器工做流，您还能够获取 POCO 类和 DbContext 供您在代码中使用。可是因为 EDMX 的存在，所以不会使用它们来建立该内存中模型。当您阅读下文时，理解很重要：EF7 将不支持基于设计器的 EDMX 模型。它没法在运行时读取 EDMX XML 来建立内存中模型。它将只使用代码优先工做流。

　　当团队发表有关这方面的博文时，引发了不少开发人员的恐慌。部分缘由是不少开发人员还没有意识到能够将数据库反向工程到 POCO 类、DbContext 和映射。换言之，您能够从数据库开始来获取代码优先模型。能够经过 2011 年初首次发布的 EF Power Tools Beta 来实现这一目的。该工具受 EF6.1 设计器支持，且确定也会受 EF7 支持。我已屡次提到“代码优先”这一名称有一些迷惑性和误导性。最初它称为“仅限代码”，后来这一名称改成“代码优先”以完美匹配“数据库优先”和“模型优先”。

　　所以，要从现有数据库开始，您无需设计器或 EDMX。

　　可是，若是您拥有现有 EDMX 模型，而且不想失去使用设计器的能力，会怎样呢？有一些第三方设计器支持实体框架，例如早已支持 EF 代码优先的 LLBLGen Pro Designer (bit.ly/11OLlN2) 以及 Devart Entity Developer (bit.ly/1yHWbB2)。查找可能提供支持 EF7 的设计器的工具以及其余可能的软件。

还要记住另外一个方法：坚持使用 EF6！

 

 

实体框架交流QQ群:  458326058，欢迎有兴趣的朋友加入一块儿交流

谢谢你们的持续关注，个人博客地址：http://www.cnblogs.com/VolcanoCloud/