代码优先vs模型/数据库优先

我认为区别在于:

代码首先

• 非常流行，因为核心程序员不喜欢任何类型的设计器，并且在EDMX xml中定义映射太复杂了。
• 对代码的完全控制(没有难以修改的自动生成代码)。
• 一般情况下，您不需要为DB操心。DB只是一个没有逻辑的存储。EF将处理创建，你不想知道它是如何工作的。
• 对数据库的手动更改很可能会丢失，因为您的代码定义了数据库。

数据库的第一

• 如果你的数据库是由dba设计的，单独开发的，或者你有现成的数据库，这是很受欢迎的。
• 您将让EF为您创建实体，在修改映射之后，您将生成POCO实体。
• 如果您想在POCO实体中添加其他特性，则必须要么T4修改模板，要么使用部分类。
• 可以手动更改数据库，因为数据库定义了域模型。你总是可以从数据库中更新模型(这个功能工作得很好)。
• 我经常一起使用VS数据库项目(只有高级版和终极版)。

第一个模型

• 恕我直言，如果你是设计师迷(=你不喜欢写代码或SQL)，这很受欢迎。
• 您将“绘制”您的模型，并让工作流生成数据库脚本，让T4模板生成POCO实体。您将失去对实体和数据库的部分控制，但对于简单的小项目，您将非常富有成效。
• 如果您想在POCO实体中添加其他特性，则必须要么T4修改模板，要么使用部分类。
• 对数据库的手动更改很可能会丢失，因为您的模型定义了数据库。如果您安装了数据库生成电源组，这将更好地工作。它将允许你在VS中更新数据库模式(而不是重新创建)或更新数据库项目。

我希望在EF 4.1的案例中，还有其他几个与代码优先和模型/数据库优先相关的特性。首先在Code中使用的Fluent API并不能提供EDMX的所有功能。我希望像存储过程映射、查询视图、定义视图等功能在首先使用模型/数据库和DbContext(我还没有尝试过)时可以工作，但在代码中不能。

在SP1之前，使用大型机型的速度非常慢(SP1之后还没有尝试过，但据说现在很容易)。

我仍然先设计我的表，然后内部构建的工具为我生成poco，因此它承担了为每个poco对象执行重复任务的负担。

当你使用源代码控制系统时，你可以很容易地跟踪poco的历史，而使用设计器生成的代码就不那么容易了。

我的POCO有一个基础，这使得很多事情变得非常简单。

我有所有表的视图，每个基本视图为外键带来基本信息，我的视图POCO派生自我的POCO类，这是非常有用的。

最后，我不喜欢设计师。

数据库优先和模型优先没有真正的区别。 生成的代码是相同的，您可以结合这两种方法。例如，你可以使用设计器创建数据库，然后你可以使用sql脚本修改数据库并更新你的模型

当你首先使用代码时，你不能在没有重新创建数据库和丢失所有数据的情况下改变模型。恕我直言，这个限制非常严格，不允许在生产中首先使用代码。目前它还不能真正使用。

代码的第二个次要缺点首先是模型构建器需要对主数据库的特权。如果您使用SQL Server Compact数据库或控制数据库服务器，这不会影响您。

代码的优点首先是非常干净和简单的代码。您可以完全控制这些代码，并可以轻松地修改和使用它作为您的视图模型。

我建议使用代码优先的方法，当你创建简单的独立应用程序，没有版本，并使用模型\数据库优先的项目，需要在生产中修改。

数据库优先方法示例:

不写任何代码: # EYZ0 < / p >

我认为它比其他方法更好，因为这种方法数据丢失更少。

代码优先似乎是后起之秀。我快速浏览了Ruby on Rails，他们的标准是代码优先，带有数据库迁移。

如果您正在构建一个MVC3应用程序，我认为Code首先具有以下优点:

• 易属性装饰 -你可以用validation, require等装饰字段。属性，这是相当尴尬的EF建模
• EF建模经常有奇怪的错误，比如当你试图重命名一个关联属性时，它需要匹配底层的元数据——非常不灵活。
• 合并并不尴尬 -当使用代码版本控制工具(如mercurial)时，合并.edmx文件是一件痛苦的事情。你是一个使用c#的程序员，你正在合并一个。edmx。代码优先则不是这样。
• 先对比代码，你就可以完全控制，没有隐藏的复杂性和未知需要处理。
• 我建议你使用包管理器命令行工具，甚至不要使用图形工具来添加一个新的控制器到脚手架视图。
• DB-Migrations -然后你也可以启用-迁移。这是如此强大。您在代码中对模型进行更改，然后框架就可以跟踪模式更改，这样您就可以无缝地部署升级，自动升级模式版本(如果需要还可以降级)。(不确定，但这可能也适用于model-first)

更新

这个问题还要求比较代码优先和EDMX模型/db优先。代码优先也可以用于以下两种方法:

• 模型先行:先编写POCOs(概念模型)，然后生成编写数据库(迁移);或
• 数据库先行:给定一个现有数据库，手动对POCOs进行编码以匹配。(不同之处在于poco不是在现有数据库的情况下自动生成的)。你可以使用使用实体框架为现有数据库生成POCO类和映射或实体框架5 -如何从现有的数据库生成POCO类来接近自动。

我首先使用EF数据库，以便对数据库配置提供更多的灵活性和控制。

EF代码优先，模型优先，起初看起来很酷，并且提供了数据库独立性，但是在这样做时，它不允许您指定我认为非常基本和常见的数据库配置信息。例如，表索引、安全元数据或主键包含多个列。我发现我想要使用这些和其他常见的数据库特性，因此必须直接进行一些数据库配置。

我发现DB第一次生成的默认POCO类非常干净，但是缺少非常有用的数据注释属性或到存储过程的映射。我使用T4模板来克服这些限制。T4模板非常棒，特别是与您自己的元数据和部分类结合使用时。

模型首先似乎有很多潜力，但在复杂的数据库模式重构过程中给我带来了很多错误。不知道为什么。

我认为Julie Lerman(《Programming Entity Framework》的作者)所写的这棵简单的“决策树”能够帮助我们更自信地做出决定:

更多信息在这里。

引用http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework中的相关部分

实体框架使用代码优先设计的3个原因

1)更少的碎屑，更少的膨胀

使用现有数据库生成.edmx模型文件 相关的代码模型导致了一大堆自动生成的代码。 请您永远不要碰这些生成的文件，以免您崩溃 或者您的更改会在下一代中被覆盖。的 Context和initializer也被挤在一起了。当 您需要向生成的模型添加功能，例如 计算的只读属性，您需要扩展模型类。 这最终成为几乎每个模型的要求，你最终

有了代码，你的手工编码模型就变成了你的数据库。确切的 您正在构建的文件将生成数据库设计。 没有额外的文件，也不需要创建类 扩展，当你想添加属性或其他 数据库不需要知道。你可以把它们加到 相同的类，只要你遵循正确的语法。见鬼，你甚至可以 生成一个模型。

. Edmx文件来可视化你的代码

2)更大的控制

当您首先使用DB时，您将受生成目的的支配 在应用程序中使用的模型。偶尔的命名 传统是不可取的。有时关系和 联想并不是你想要的。其他时间非瞬态

虽然模型生成问题几乎总是有解决方案的 你可能会遇到，先去代码会给你完整的和好的 从一开始就是粒度控制。你可以控制两者的方方面面 您的代码模型和数据库设计从您的舒适 业务对象。你可以精确地指定关系，约束， 和关联。您可以同时设置属性字符限制 和数据库列大小。您可以指定相关的集合 都是急于加载，或根本不被连载。简而言之，你就是 你要负责更多的事情，但你完全控制你的应用程序 设计。< / p >

3)数据库版本控制

这是一个大问题。对数据库进行版本控制很难，但首先要处理代码 代码优先迁移更有效。因为你的 数据库模式完全基于代码模型，按版本划分 控制源代码就是在帮助数据库版本化。 你负责控制你的上下文初始化 可以帮助您做一些事情，如种子固定业务数据。你也 负责创建代码第一次迁移

当您第一次启用迁移时，配置类和初始化 生成迁移。最初的迁移是当前的模式 或者你的基线版本1.0。从这一点开始，您将添加迁移 它们都有时间戳和描述符来帮助处理 版本排序。当您从包中调用add-migration时 Manager，将生成一个包含所有内容的新迁移文件 在UP()和代码模型中自动更改的 ()函数。UP函数将更改应用到数据库， DOWN函数在你想要的情况下删除这些相同的更改 回滚。更重要的是，您可以编辑这些迁移文件来添加 其他更改，如新的视图、索引、存储过程和 不管。它们将成为一个真正的版本控制系统 数据库模式。< / p >

依我之见，我认为所有的模型都有很好的地方，但我认为模型优先方法的问题是，在许多大型企业中，DBA控制数据库，如果不使用数据库优先方法，就无法获得构建应用程序的灵活性。我参与过许多项目，当涉及到部署时，他们想要完全控制。

因此，尽管我同意所有可能的变化，代码优先，模型优先，数据库优先，您必须考虑实际的生产环境。因此，如果您的系统将是一个拥有许多用户和DBA的大型用户基础应用程序，那么您可能会考虑数据库作为首选——这只是我的观点。

我认为代码优先的优点之一是，你可以备份你对版本控制系统(如Git)所做的所有更改。因为所有的表和关系都存储在本质上只是类中，所以您可以回顾过去，看看数据库以前的结构是什么。