我知道这个问题之前已被多次询问，因为我已经阅读了很多关于利弊等主题的帖子，但我仍然无法确定哪种方法适合我。我是网络编程的新手，来自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的另一个名称吗？为什么我找不到Microsoft的任何教程，显示这些与MVC 3一起使用的伙伴/视图模型？
- 我试图在2个表之间建立基本的1对1关系。在模型中，您必须将每个表的标识键设置为相同的字段，而不是在其中一个表中使用FK，当您有3个或更多表通过1对1关系相互链接时，这可能会有点混乱。在代码中首先解决这个问题的方法是使用模型构建器并手动设置它。我认为在MF中你可以通过进入我根本不热衷的XML来改变关系。
- 对代码优先问题提供更多支持/帮助
我对使用Code First方法犹豫不决的原因是：
- 我是新手编码员。
- 我发现随着项目的扩展，跟踪表格和关系变得非常困难。
- 没有模型图，我不得不说我真的喜欢这个想法。
- 通过配置类将实体映射到数据库我觉得不可能:)。
- 更新表格需要更改代码和数据库。在模型中，首先只对模型进行一次更改，该模型将自动更新数据库和代码，如果您使用好友类，则可能还需要更新这些类。
现在我也看到人们在某种程度上结合了Code First和Database的第一种方法，因为你不要让Code First生成你的数据库，而是手动创建一个数据库，并使用代码优先API到EF来实现它。
我的头脑旋转着所有的选择和缺点以及利弊。我只是想继续创建我的网站，而不是思考采取哪种方法。 任何人都可以根据我所说的和/或他们认为将来会成为更主流的方式，给我一些他们认为哪种方法最好的见解？
非常感谢戴夫
答案 0 :(得分：37)
这个问题太长了。您应该在下次将问题分解为多个单独的问题。
您是一个数据库人员，因此最适合您的方法是增量数据库优先方法，您可以在数据库（或VS数据库工具）中定义内容并从数据库更新模型。这将使您可以很好地控制数据库，并允许您逐步构建应用程序和数据库。为什么我认为你会喜欢它：
有关differences between DB first, Model first and Code first的更多信息。另一个answer describes differences between code-first and working with designer。
我认为这是最艰难的方式。您将首先定义数据库，然后使用DbContext流畅的API或数据注释来定义映射。这需要很好地理解EF以及DbContext API中使用的默认约定的映射和理解背后的所有原理。它将为您提供对映射的良好和明确的控制，但这是最需要做的工作。这绝对是最难的方式。此外，它不是假设使用，因为DbContext API主要是为代码优先方法创建的。
一旦开始使用EDMX（实体设计师），您可以选择使用DbContext Generator T4模板或POCO Generator T4模板。决定取决于您 - 您可以使用DbContext API（第一个模板）或ObjectContext API（第二个模板），这些文档更好地记录，您还可以使用两本好书：
我所知道的ObjectContext API来自这些书，作者的博客和练习+反射器。
DbContext API目前没有任何书籍。您可以查看一些主要网站以获取相关信息：
我所知道的DbContext API来自这些博客和练习+反射器。
即使您首先使用代码，您仍然可以使用类图来可视化您的类图（它与EDMX不同，但它足以让您了解全局）。
搜索Stack Overflow或MSDN forum将为您提供有关两种API所遇到的大多数问题的答案。
使用实体框架与MVC 3没有任何具体内容。用于数据验证注释的Buddy类被认为是不好的做法。伙伴类是用作实体上应用的元数据持有者的单独类。视图模型是用于在控制器和视图之间传输数据的类。视图模型应该针对每个视图具有自己的验证注释，因为在使用相同的实体类型时，您通常需要在应用程序的不同屏幕中进行不同的验证 - 例如，编辑和插入屏幕可以具有不同的验证要求。
尽管它不被认为是一种好的做法，但可以向实体添加验证 - 您可以create buddy class for each your entity manually或者您可以尝试修改T4模板以直接为您生成注释（这很难）
是EF要求仅在主键之上创建一对一关系。原因是EF不支持唯一键/约束。没有办法解决这个问题，在数据库中使用唯一键不会改变它。
答案 1 :(得分：8)
这相对简单。如果您不关心数据库模型，请先使用代码。如果这样做，请先使用Model（或Database First）。它取决于您的重点所在，以数据为中心或以代码为中心。
答案 2 :(得分：3)
我看过这两种方法和我 确实只赞成实体模型方法 因为我喜欢简单的 设计师，我喜欢看到整体 在我面前的模型，它显示了 一张快照中的整体图片。也， 我不是一个强大的程序员 对它产生的方式印象深刻 POCO使用DbContext 生成器模板并完成所有 各类之间的联系。
<强> +
通过实体将实体映射到数据库 我找到的配置类 不可能:)。
= 首先使用模型
如果创建好友是好的做法 上课为什么我找不到很多 教程为MVC 3展示了这个？是 Buddy Classes View的另一个名称 楷模？为什么我找不到任何东西 微软的教程展示了这些 与MVC 3一起使用的伙伴/视图模型？
这可能是因为代码优先就像块中的新孩子。这就是为什么MVC3主要是代码优先的教程。模型优先是“更多”，并且在MVC2时可能是最受欢迎的解决方案。
顺便说一下：你已经知道我的意见，你应该使用，你最喜欢的或者最舒服的（正如我上次你提到你的那样），但我只是想在这里添加一些内容：）评论后修改：
看看这些东西，这将首先帮助你解决代码：
Creating an Entity Framework Data Model for an ASP.NET MVC Application (1 of 10) Scaffold your ASP.NET MVC 3 project with the MvcScaffolding package
++来自MIX11的这些精彩视频，频道9：
Scott Hanselman showing new stuff in his awesome way as usually
Steve Sanderson showing power of MvcScaffolding
答案 3 :(得分：0)
如果这是模型优先的首要问题，您可以使用任何版本的MVC中的模型第一个示例。 MVC处理“模型”的方式在各版本之间并没有太大差异。当然，视图模型等都有增强功能，但是对于较旧的教程，你应该没问题。
我首先更喜欢代码，因为我觉得有数据库模型和域模型，它们用于不同的目的。数据库组织是针对数据库的性能和大小而不是为了帮助您的应用程序。拥有自己的模型可以让您专注于应用程序中的状态需求，而不管数据库是什么。
现在，您可以先从模型中获取此模型，但您更有可能以这种方式考虑数据库而不是您的需求...尤其是如果你是这个新手。
只需2美分。