EF模型优先或代码优先方法？

Question

我知道这个问题之前已被多次询问,因为我已经阅读了很多关于利弊等主题的帖子,但我仍然无法确定哪种方法适合我.我是网络编程的新手,来自SQL DB管理员/报告编写背景.我决定尝试建立自己的网站,最终可能会有更多的30 -40桌子.

我看了两种方法,我确实赞成实体模型方法,因为我喜欢设计师的简单性,我喜欢在我面前看到整个模型,它在一个快照中显示整体画面.另外,我不是一个强大的程序员,我对它使用DbContext生成器模板生成POCO的方式印象深刻,并完成了类之间的所有链接.

然而,虽然我喜欢模型第一种方法,但我觉得有一些缺点,我不确定它们是否是真正的缺点,或者我只是对模型第一种方法和代码第一种方法知之甚少,因为我仍然非常新的.

我对使用Model First方法犹豫不决的原因是:

- 主要是因为我很难找到使用MVC 3的模型第一种方法的教程.我发现使用DbContext的最好的教程是Julie Lerman,但她不涉及对使用数据注释和制作其他内容很重要的伙伴类重新生成POCO时未丢失的更改.大多数与MVC 3相关的教程似乎都使用Code第一种方法.大多数人都说这是因为导师不想专注于EF,而是在tuts中展示更多的MVC.我个人认为这是因为微软支持Code First方法而不是其他方法:)

- 如果创建好友类是一个好习惯,为什么我找不到很多教程来展示MVC 3呢？Buddy Classes是View Models的另一个名称吗？为什么我找不到微软展示这些与MVC 3一起使用的伙伴/视图模型的教程？

- 我试图在2个表之间建立基本的1对1关系.在模型中,您必须将每个表的标识键设置为相同的字段,而不是在其中一个表中使用FK,当您有3个或更多表通过1对1关系相互链接时,这可能会有点混乱.在代码中首先解决这个问题的方法是使用模型构建器并手动设置它.我认为在MF中你可以通过进入我根本不热衷的XML来改变关系.

- 更多支持/帮助解决代码问题

我对使用Code First方法犹豫不决的原因是:

- 我是新手编码员.

- 我发现随着项目的扩展,跟踪表格和关系变得非常困难.

- 没有模型图,我不得不说我真的喜欢这个想法.

- 通过配置类将实体映射到数据库我发现不可能:).

- 更新表将需要更改代码和数据库.在模型中,首先只对模型进行一次更改,该模型将自动更新数据库和代码,如果您使用好友类,则可能还需要更新这些类.

此外,我现在看到人们在某种程度上结合了Code First和Database的第一种方法,因为你不要让Code First生成你的数据库,而是手动创建一个数据库,并使用代码优先API到EF来实现它.

我的头脑旋转着所有的选择和缺点以及利弊.我只是想继续创建我的网站,而不是思考采取哪种方法.任何人都可以根据我所说的和/或他们认为未来更主流的方式,给我一些洞察他们认为最好的方法吗？

非常感谢戴夫

Answer 1

这是一个太长的问题.您应该在下次将问题分解为多个单独的问题.

代码优先x模型优先x数据库优先

您是数据库人员,因此最适合您的方法是增量数据库优先方法,您可以在数据库(或VS数据库工具)中定义内容并从数据库更新模型.这将使您可以很好地控制数据库,并允许您逐步构建应用程序和数据库.为什么我认为你会喜欢它:

• 您以前做过SQL DB Admin - 您可能对DB有所了解以及如何设计它们以获得性能 - EF将不会为您做任何事情.EF不会为您创建索引等.
• 30-40表意味着您不会在一次拍摄中构建模型.您将从小型号开始并不断增长.一旦开始在DB中进行更改或添加初始化数据,您就不希望丢失这些更改和数据.代码优先只允许删除整个数据库并从头开始重新创建.模型优先允许逐步构建数据库,但您需要实体设计器数据库生成Power Pack和VS 2010 Premium或Ultimate($ 5.000- $ 10.000).

更多关于DB first,Model first和Code first之间的差异.另一个答案描述了代码优先和与设计师合作之间的差异.

DbContext API +数据库优先+ Fluent映射

我认为这是最艰难的方式.您将首先定义数据库,然后使用DbContext流畅的API或数据注释来定义映射.这需要很好地理解EF以及DbContext API中使用的默认约定的映射和理解背后的所有原理.它将为您提供对映射的良好和明确的控制,但这是最需要做的工作.这绝对是最难的方式.此外,它不应该被使用,因为DbContext API主要是为代码优先方法创建的.

DbContext API x ObjectContext API

一旦开始使用EDMX(实体设计师),您可以选择使用DbContext Generator T4模板或POCO Generator T4模板.决定取决于您 - 您可以使用DbContext API(第一个模板)或ObjectContext API(第二个模板),这些文档更好地记录,您还可以使用两本好书:

• 编程实体框架
• 实体框架收据

我所知道的ObjectContext API来自这些书,作者的博客和练习+反射器.

DbContext API目前没有任何书籍.您可以查看一些主要网站以获取有关它的信息:

• ADO.NET团队博客
• Julia Lerman的博客
• Morteza Manavi的博客

我所知道的DbContext API来自这些博客和练习+反射器.

即使您首先使用代码,您仍然可以使用类图来可视化您的类图(它与EDMX不同,但它足以获得全局图).

在Stack Overflow或MSDN论坛上搜索将为您提供有关两个API的大多数问题的答案.

MVC 3

使用实体框架与MVC 3没有任何具体关系.用于数据验证注释的Buddy类被认为是不好的做法.伙伴类是用作实体上应用的元数据持有者的单独类.视图模型是用于在控制器和视图之间传输数据的类.视图模型应该针对每个视图具有自己的验证注释,因为在使用相同的实体类型时,您通常需要在应用程序的不同屏幕中进行不同的验证 - 例如,编辑和插入屏幕可以具有不同的验证要求.

尽管它不被认为是一种好的做法,但可以向实体添加验证 - 您可以手动为每个实体创建好友类,也可以尝试修改T4模板直接为您生成注释(这很难) .

一对一的关系

是EF要求仅在主键之上创建一对一关系.原因是EF不支持唯一键/约束.没有办法解决这个问题,在数据库中使用唯一键不会改变它.

Answer 2

它相对简单.如果您不关心数据库模型,请先使用代码.如果这样做,请先使用Model(或Database First).它取决于您的重点所在,以数据为中心或以代码为中心.