当看到这个时，我也很震惊。估计绝大多数的人和我一样，这些年来，一直不知道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打造成一个轻量级的、可扩展的版本。它将是一个全新的平台和数据存储（data stores)。我们在北美技术大会（TechEd North America)关于EF的会议中，同样有提及EF7的计划。
在EF7之前，存储（译注：这里当动词用）模型有两种方式，一种是基于XML的EDMX文件格式，一种是基于代码。从EF7开始，我们将不再支持EDMX格式，转而只支持单一的基于代码风格的存储。对于移除对基于XML的EDMX这事，引起很多人的担忧，他们中间，多部分人是源于对“EF7 将只支持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）”会更清晰些。
很明显，我们得维护两种不同的建模方式。除此之外，我还别的原因让我选择在EF7中只支持基于代码建模（code-base modeling）的方式。
1、 源代码控制合并、冲突、代码审审变得困难。当把整个模型存储在一个xml文件时，我们收到了很多开发人员的反馈，模型上一个简单的改动，将导致xml中产生较大的差异。别一方面，开员人员得合并和重新审查源代码。
2、 开发人员知道如何编写和调试代码。在一些简单的项目中，设计器无可否认的带来便利。然而，很多项目的需求却超了出了设计器的能力范围。遇到这种情况时，需要修改xml文件里的一些东西，但这对多数开发人员来说，这比修改代码要艰难很多。
3、 根据环境自定义模型的能力。我们从客户那里听到这是一个很普遍的需求，比如，在程序运行时你需要指定架构或是表前缀的多租户数据库（Multi-tenant database）。也在可能会根据不同的数据库提供商在运行时轻微调整你的模型。实现这些需求，使用操作基于xml文件的模型会异常艰难。另一方面，在代码中使用条件逻辑来定义模型会很容易实现 。
4、基于代码的模型不会重复。因为CLR类型同样也能构建模型，以及有照顾一般配置（take care of common configration)的约定。 假设一个Blog实体拥有一个BlogId主键。在基于EDMX的模型中，在CLR类中会有一个BlogId属性，一个xml BlogId属性（外加列和映射）以及另外的一些xml内容来标识BlogId作为一个实体键。但在基于代码的模型中，拥有一个CLR类型中的BlogId属性就够了。
5、在代码中提供有用的错误信息更容易。我们都见过”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中，所有的模型均通过代码来表示了。有工具可以从一个已存在数据库逆向生成一个模型（像在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的喜爱超过了基于代码建模。
与此同时，我们必须平衡时间和资源，我们会分享我们认识最好的特性和功能来帮助开发人员编写一个成功的应用。 这并不是我们轻率，因为对于实体框架的长期发展和用户来说，这是最好的选择。最终的目标是提供一个更快速的、更简单的使用栈，以及减少支持高需求的成本。我们一直朝着这样方向努力。
翻译中，肯定有很多不当的地方，恳请你的指正，同时，请点击下边的推荐来支持。谢谢！希望你有收获。
相关文章
