代码优先与模型/数据库优先[关闭]

使用实体框架4.1代码优先于模型/数据库优先使用EDMX图表有什么优缺点？

我正在尝试彻底理解使用EF 4.1构建数据访问层的全部方法。 我正在使用Repository模式和IoC 。

我知道我可使用代码优先方法：手动定义个人实体和上下文，并使用ModelBuilder来微调模式。

我还能够建立EDMX图并选择使用T4模板生成相同POCO类的代码生成步骤。

在这两种状况下，我最终都获得了与ORM无关的POCO对象和源自DbContext上下文。

数据库优先彷佛最吸引人，由于我能够在企业管理器中设计数据库，快速同步模型并使用设计器对其进行微调。

那么这两种方法有什么区别？ 是仅仅关于VS2010与企业管理器的偏好？

---

#1楼

代码优先彷佛是后起之秀。 我快速浏览了Ruby on Rails，它们的标准是代码优先，具备数据库迁移。

若是您正在构建MVC3应用程序，我相信Code首先具备如下优点：

• 简单的属性修饰 - 您可使用验证，要求等属性来装饰字段，这对于EF建模来讲很是尴尬
• 没有奇怪的建模错误 - EF建模一般会出现奇怪的错误，例如当您尝试重命名关联属性时，它须要匹配底层的元数据 - 很是不灵活。
• 合并并不尴尬 - 当使用像mercurial这样的代码版本控制工具时，合并.edmx文件是一件痛苦的事。 你是一个习惯于C＃的程序员，你正在合并一个.edmx。 代码优先不是这样。
• 首先对比代码，你能够彻底控制，而不须要处理全部隐藏的复杂性和未知数。
• 我建议您使用Package Manager命令行工具，甚至不使用图形工具向scaffold视图添加新控制器。
• 数据库迁移 - 而后您还能够启用迁移。 这太强大了。 您能够在代码中更改模型，而后框架能够跟踪架构更改，所以您能够无缝地部署升级，并自动升级架构版本（若是须要，能够降级）。 （不肯定，但这可能也适用于模型优先）

更新

该问题还要求将代码优先与EDMX模型/ db-first进行比较。 代码优先也能够用于这两种方法：

• 模型优先 ： 首先编码POCO（概念模型），而后生成数据库（迁移）; 要么
• Database-First ：给定现有数据库， 手动编码POCO以匹配。 （这里的区别在于POCO不是自动生成的，而是给出现有的数据库）。 您能够接近自动，可是使用Generate POCO类和使用Entity Framework或Entity Framework 5 的现有数据库的映射 - 如何从现有数据库生成POCO类 。

---

#2楼

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

EF代码优先和模型首先看起来很酷，并提供数据库独立性，可是在这样作时它不容许您指定我认为很是基本和常见的数据库配置信息。 例如，表索引，安全元数据或具备包含多个列的主键。 我发现我想使用这些和其余常见的数据库功能，所以不管如何都必须直接进行一些数据库配置。

我发如今DB中首先生成的默认POCO类很是干净，但缺乏很是有用的数据注释属性或映射到存储过程。 我使用T4模板来克服其中一些限制。 T4模板很是棒，特别是与您本身的元数据和部分类结合使用时。

模型首先彷佛有很大的潜力，但在复杂的数据库模式重构过程当中给了我不少错误。 不知道为何。

---

#3楼

我认为“编程实体框架”的做者Julie Lerman的这个简单的“决策树”应该有助于更有信心地作出决定：

更多信息在这里 。

---

#4楼

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

使用代码优先设计实体框架的3个理由

1）减小臃肿，减小膨胀

使用现有数据库生成.edmx模型文件和相关的代码模型会产生大量自动生成的代码。 你恳求永远不要触摸这些生成的文件，以避免你破坏某些东西，或者你的更改会被下一代覆盖。 上下文和初始化程序也在这个混乱中被卡在一块儿。 当您须要向生成的模型添加功能时，例如计算的只读属性，您须要扩展模型类。 这最终成为几乎全部模型的要求，并最终为全部内容提供扩展。

使用代码，您的手动编码模型将成为您的数据库。 您正在构建的确切文件是生成数据库设计的缘由。 没有其余文件，当您想要添加属性或数据库不须要了解的任何其余内容时，无需建立类扩展。 只要遵循正确的语法，您就能够将它们添加到同一个类中。 哎呀，若是须要，您甚至能够生成一个Model.edmx文件来显示您的代码。

2）更好的控制

当您首先使用数据库时，您将受到为您的应用程序使用的模型生成的内容的摆布。 偶尔命名约定是不合须要的。 有时，关系和联想并非你想要的。 其余时候，与延迟加载的非瞬态关系会对您的API响应形成严重破坏。

虽然几乎总有一个解决方案可能会遇到模型生成问题，可是代码首先会为您提供完整且细粒度的控制。 您能够在温馨的业务对象中控制代码模型和数据库设计的各个方面。 您能够精确指定关系，约束和关联。 您能够同时设置属性字符限制和数据库列大小。 您能够指定要急切加载哪些相关集合，或者根本不进行序列化。 简而言之，您负责更多的东西，但您能够彻底控制您的应用程序设计。

3）数据库版本控制

这是一个很大的问题。 版本控制数据库很难，可是代码优先和代码优先迁移，它更有效。 由于您的数据库模式彻底基于您的代码模型，因此经过控制源代码的版本，您能够帮助对数据库进行版本控制。 您负责控制上下文初始化，这能够帮助您执行诸如播种固定业务数据之类的操做。 您还负责建立代码首次迁移。

首次启用迁移时，将生成配置类和初始迁移。 初始迁移是您当前的架构或基准v1.0。 从那时起，您将添加时间戳并带有描述符标记的迁移，以帮助排序版本。 从包管理器调用add-migration时，将生成一个新的迁移文件，其中包含在UP（）和DOWN（）函数中自动更改代码模型中的全部内容。 UP函数将更改应用于数据库，DOWN函数在要回滚的事件中删除相同的更改。 此外，您还能够编辑这些迁移文件以添加其余更改，例如新视图，索引，存储过程以及其余任何更改。 它们将成为数据库模式的真正版本控制系统。

---

#5楼

恕我直言，我认为全部的模型都有一个很好的地方，但我在模型第一种方法中遇到的问题是在许多大型企业中，DBA控制数据库，你不能灵活地构建应用程序而不使用数据库第一种方法。 我参与了许多项目，在部署时，他们须要彻底控制。

所以，尽管我赞成Code First，Model First，Database first的全部可能变体，但您必须考虑实际的生产环境。 所以，若是您的系统将成为一个大型用户群应用程序，其中包含许多用户而且DBA正在运行该节目，那么您可能会认为数据库第一个选项只是个人意见。