EDMX图中使用实体框架4.1代码优先优于模型/数据库优先的优点和缺点是什么?

我试图充分理解使用EF 4.1构建数据访问层的所有方法。我使用存储库模式和IoC。

我知道我可以使用代码优先的方法:手动定义实体和上下文,并使用ModelBuilder对模式进行微调。

我还可以创建一个EDMX图并选择一个代码生成步骤,该步骤使用T4模板来生成相同的POCO类。

在这两种情况下,我最终得到的POCO对象是ORM不可知的,而上下文则来自DbContext。

数据库优先似乎是最有吸引力的,因为我可以在企业管理器中设计数据库,快速同步模型并使用设计器对其进行微调。

那么这两种方法有什么不同呢?仅仅是VS2010 vs企业管理器的偏好问题吗?


当前回答

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

其他回答

数据库优先方法示例:

无需编写任何代码: ASP。数据库优先/数据库优先

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

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

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

Easy attribute decoration - You can decorate fields with validation, require, etc.. attributes, it's quite awkward with EF modelling No weird modelling errors - EF modelling often has weird errors, such as when you try to rename an association property, it needs to match the underlying meta-data - very inflexible. Not awkward to merge - When using code version control tools such as mercurial, merging .edmx files is a pain. You're a programmer used to C#, and there you are merging a .edmx. Not so with code-first. Contrast back to Code first and you have complete control without all the hidden complexities and unknowns to deal with. I recommend you use the Package Manager command line tool, don't even use the graphical tools to add a new controller to scaffold views. DB-Migrations - Then you can also Enable-Migrations. This is so powerful. You make changes to your model in code, and then the framework can keep track of schema changes, so you can seamlessly deploy upgrades, with schema versions automatically upgraded (and downgraded if required). (Not sure, but this probably does work with model-first too)

更新

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

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

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

更多信息在这里。

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

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

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

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

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

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

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

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

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