41

我知道这个问题已经被问过很多次了，因为我已经阅读了很多关于利弊等主题的帖子，但我仍然无法决定哪种方法适合我。我对网络编程非常陌生，并且来自 SQL DB 管理员/报告写作背景。我决定尝试建立自己的网站，将来可能会有 30 -40 张桌子。

我已经研究过这两种方法，并且我确实喜欢实体模型方法，只是因为我喜欢设计器的简单性，而且我喜欢在我面前看到整个模型，它在一张快照中显示了整体画面。此外，我不是一个强大的程序员，我对它使用 DbContext 生成器模板生成 POCO 并在类之间进行所有链接的方式印象深刻。

然而，虽然我喜欢模型优先方法，但我觉得有一些缺点，我不确定它们是否是实际的缺点，或者我只是对模型优先方法和代码优先方法不够了解，因为我仍然非常对此很陌生。

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

- 主要是因为我很难找到关于使用 MVC 3 的模型优先方法的教程。我发现使用 DbContext 的最佳教程是 Julie Lerman 的，但她没有涵盖对于使用数据注释和制作其他重要的伙伴类重新生成 POCO 时不会丢失的更改。大多数与 MVC 3 相关的教程似乎都使用代码优先方法。大多数人说这是因为导师不想专注于EF，而是在tuts中展示更多的MVC。我个人认为这是因为微软支持 Code First 方法而不是其他方法 :)

- 如果创建伙伴类是一种很好的做法，为什么我找不到很多针对 MVC 3 的教程？Buddy Classes 是视图模型的另一个名称吗？为什么我找不到 Microsoft 提供的任何教程来展示这些与 MVC 3 一起使用的伙伴/视图模型？

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

- 更多关于代码优先问题的支持/帮助

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

-我是新手编码员。

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

- 没有模型图，我不得不说我真的很喜欢这个想法。

-通过配置类将实体映射到数据库我觉得不可能:)。

-更新表将需要更改代码和数据库。在模型中，只有一个模型更改会自动更新数据库和代码，如果你使用伙伴类，你可能也必须更新这些。

此外，现在我看到人们在某种程度上结合了 Code First 和 Database first 方法，因为您不让 Code First 生成数据库，而是手动创建数据库并使用 Code First API 到 EF 来获取它。

我的头脑在思考所有的选择、缺点和利弊。我只想继续创建我的网站，而不是考虑采用哪种方法。任何人都可以根据我所说的和/或他们认为将来会成为主流的方法，给我一些关于他们认为最好的方法的见解吗？

非常感谢戴夫

4

4 回答 4

37

这个问题太长了。下次你应该把你的问题分解成多个单独的问题。

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

您是数据库专家，因此对您来说最好的方法是增量数据库优先方法，您可以在 DB（或 VS 数据库工具）中定义内容并从数据库更新模型。这将使您对数据库有很大的控制权，并允许您以增量方式构建应用程序和数据库。为什么我认为你会喜欢它：

  • 您之前做过 SQL DB Admin - 您可能知道一些关于 DB 的知识以及如何设计它们以获得性能 - EF 不会为您做任何事情。EF 不会为您创建索引等。
  • 30-40张桌子意味着您不会一次构建模型。您将从小型模型开始并不断发展它。一旦您开始在数据库中进行更改或添加初始化数据，您将不希望丢失这些更改和数据。代码优先只允许删除整个数据库并从头开始重新创建它。模型优先允许逐步构建数据库，但您需要Entity Designer Database Generation Power pack和 VS 2010 Premium 或 Ultimate ($5.000-$10.000)。

更多关于DB first、Model first 和 Code first 之间的区别。另一个答案描述了代码优先和使用设计器之间的区别。

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

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

DbContext API x ObjectContext API

开始使用 EDMX（实体设计器）后，您可以选择使用 DbContext Generator T4 模板或 POCO Generator T4 模板。决定权在你手中——你可以使用 DbContext API（第一个模板）或 ObjectContext API（第二个模板），它的文档记录要好得多，你还可以使用两本好书：

我对 ObjectContext API 的了解都来自这些书籍、作者的博客和实践 + Reflector。

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

我对 DbContext API 的了解都来自这些博客和实践 + Reflector。

即使您首先使用代码，您仍然可以使用类图来可视化您的类图（它与 EDMX 不同，但足以了解全局）。

在 Stack Overflow 或MSDN 论坛上进行搜索将为您提供使用这两种 API 时遇到的大多数问题的答案。

MVC 3

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

尽管事实上它不被认为是好的做法，但向实体添加验证是可能的 - 您可以手动为每个实体创建伙伴类，也可以尝试修改 T4 模板以直接为您生成注释（这很难） .

一对一关系

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

于 2011-04-27T07:16:50.390 回答
8

它相对简单。如果您不关心数据库模型，请先使用代码。如果这样做，请先使用模型（或先使用数据库）。这仅取决于您的关注点在哪里，以数据为中心还是以代码为中心。

于 2011-04-26T22:41:51.063 回答
3

我已经研究过这两种方法，并且我确实喜欢实体模型方法，只是因为我喜欢设计器的简单性，而且我喜欢在我面前看到整个模型，它在一张快照中显示了整体画面。此外，我不是一个强大的程序员，我对它使用 DbContext 生成器模板生成 POCO 并在类之间进行所有链接的方式印象深刻。

+

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

=首先使用模型

如果创建伙伴类是一种好习惯，为什么我找不到很多针对 MVC 3 的教程？Buddy Classes 是视图模型的另一个名称吗？为什么我找不到 Microsoft 提供的任何教程来展示这些与 MVC 3 一起使用的伙伴/视图模型？

这可能是因为代码优先就像是一个新手。这就是为什么大多数 MVC3 的代码优先教程。模型优先“老得多”，可能是 MVC2 时代最受欢迎的解决方案。

顺便说一句：你已经知道我的意见，你应该使用，你最喜欢或觉得最舒服的（正如我上次你问这个问题时告诉你的那样），但我只是想在这里添加一些东西 :)

评论后编辑：

看看这些东西，这将帮助您首先编写代码：

为 ASP.NET MVC 应用程序创建实体框架数据模型 (1 of 10) 使用 MvcScaffolding 包搭建 ASP.NET MVC 3 项目

++ 这些来自 MIX11 在第 9 频道的精彩视频：
Scott Hanselman 以他令人敬畏的方式展示了新的东西，
Steve Sanderson 展示了 MvcScaffolding 的力量

于 2011-04-26T22:47:44.943 回答
0

如果这是模型优先的主要问题，您可以使用任何版本的 MVC 中的模型优先示例。MVC 处理“模型”的方式在不同版本之间并没有真正的不同。当然，对视图模型等进行了增强，但是您应该可以使用较旧的教程。

我更喜欢代码优先，因为我觉得有数据库模型和域模型，它们有不同的用途。数据库组织是为了数据库的性能和大小，而不是帮助您的应用程序。拥有自己的模型可以让您专注于应用程序中的状态需求，而不管数据库如何。

现在，您可以先从模型获取此模型，但您更有可能以这种方式考虑数据库而不是您的需求......尤其是。如果你是这方面的新手。

只是我的2美分。

于 2011-04-26T22:45:42.657 回答