我的问题与实体框架方面具体有关.
我试图在以下之间作出选择：
>代码首先到现有的数据库
> EF Designer到现有数据库(首先是数据库)
我知道我们可以使用EF从代码首先或从EF设计器生成数据库,但是我们更愿意以传统的方式对数据库进行完全的控制,从而排除了EF选项,生成数据库.
在互联网上可以找到的与Code First有关的大部分内容涉及创建新的数据库,然后使用代码迁移.当讨论首先处理数据库时,讨论会让EF Designer受益.示例：Code-first vs Model/Database-first
我喜欢将Code First与现有的数据库结合使用.
以下是我赞成这个选择的考虑,我想知道是否还有其他任何事情需要考虑,以及我的假设/想法是否正确.
首先到现有数据库
>在开始时将有大量的类来构造,但是我们可以从EF模型向导中进行初始生成.
>然后可以使用任何自定义属性修改类,或者删除我们不需要的任何东西,而不是要求我们扩展任何类的EF Designer.
>缺点是对数据库的任何更改都必须手动添加到我们的类中,与使用易于更新的设计器不同.
编辑：
我想我在这方面感到困惑.从阅读看,数据优先的正确方法似乎是为所有自动生成的类创建部分类,然后作为“业务”层的一部分对部分类进行任何修改.
因此,我的想法从支持“数据库代码优先”到使用EF Designer到现有数据库,然后创建部分类而改变.
解决方法
唯一的区别是：
>使用设计器,您可以图形化,容易地设置属性,列名称等
>使用Code First,您必须使用惯例Fluent API或属性来设置这些属性,列名称,数据类型等
通过代码优先,唯一的优点是,一旦您同步了Code First模型(请参阅“Code First也是EDM,但有限”)和数据库,您可以开始使用Migrations,并使用它们来演进模型,以后可以更改应用到生产DB(每当发布新版本时).使用图形模型,您无法使用迁移,必须直接从Visual Studio升级Db,或者手动创建sql DDL脚本.
Code First也是一个EDM,但缺少几个功能
无论使用Code First还是绘制模型,都将生成EDM(实体数据模型).如果您习惯于设计数据库,可能您会更加舒适地使用设计器.注意EF Core(前EF7)下面的笔记！
然而,Code First生成的EDM有一些设计师没有的限制.
Code First最出色的限制是,在设计器中,您可以轻松地从BD映射用户定义的函数,例如标量和表值函数以及存储过程.使用代码优先还有更多的限制.
在EF 6.1中,大多数这种局限性都消失了,但是做出映射还是有点困难(实际上,截至今天,2014年,there’s only a sample和a simple Nuget package关于如何做的).
截至2017年3月,非核心EF(即EF Core 6.1)不再更新. MS可能会解决bug,如果它们出现,但不要指望进一步的更改
EF Core,fomer EF7的变化(截至2015年)
目前,微软正在开发EF 7,但也保留了EF 6.x.目前的建议是继续使用EF 6一段时间,因为EF 7还不够成熟.
EF 7正在从头开始,以克服继承的ObjectContext,这对实现新功能构成了极大的限制.但它实现最广泛使用的DbContext几乎没有变化.因此,如果您使用DbContext,您将有一个简单的迁移路径到新的EF版本.
然而,有一个非常重要的变化：在EF Core(前EF7)中,EDM模型反对代码优先模型.因此,如果您想使用当今的技术,并确保轻松升级到新版本,请勿使用Model First或Database First：使用Code First.微软有这样一个重要的理由：Code First在一个具有版本控制的环境中工作得更好,并允许使用Migrations.无论如何,tou仍然可以以图形方式(使用Power Toools)查看模型,或使用第三方工具使用设计人员创建模型(目前的几种商业解决方案将支持EF7).
注意：为什么团队环境中的Code First更好？如果几个团队成员修改了模型,就可以在多个代码文件中合并更改更容易,而不是在一个大的XML文件中使用很多定义模型的行.了解这个hugh XML文件中的版本之间的变化也更难.对于中型或大型项目,我建议您尽快移至“代码第一”
