EF模型优先和数据库优先的替代方案是什么？

Question

自从MSFT正式放弃了Model First和Database First，是否有其他替代方案呢？我正在考虑使用DevArt Entity Developer。还有其他替代方案可以考虑吗？

在MSFT宣布放弃Database First之前，我曾考虑使用Sparx EA来维护数据库，然后使用EF Database First从数据库更新模型，但是他们拒绝承认现在需要从他们的设计模型生成Code First，即使EF不再支持Database First。EA将生成POCO类，但不会生成任何CodeFirst变体，而且我不想手动不断更新。

- Dave

---

由于CodeFirst本质上是一个DbSet<POCO>，那么POCO类怎么不是“CodeFirst变体”呢？只需取出它们创建的类，创建一个上下文并为每个类添加一个DbSet<T>，然后就可以开始了... - Claies

微软在哪里放弃了这些替代方案？至少在VS 2013中，您仍然可以从模型生成数据库。 - Mare Infinitus

你总是能够从数据库中“生成”实体。他们唯一要删除的是“设计师”，这将使每个人受益！ - Michal Ciechan

@Mare - 宣布支持 EF7。仅限 Code First，但允许您从数据库生成一次。然后您必须继续使用 Code First。 - Dave

我还在努力理解这里的问题所在；如果您花费了任何时间使用 Code First，那么您就会明白 DbContext 与 Model First 或 Database First 创建的 DbContext 没有任何区别，并且 Classes 只是由您创建的 POCO classes，而不是使用输出 XML 和 .TT 文件生成类的设计师。如果您有另一个可以生成 POCO 类的工具，则在功能上没有任何区别。 - Claies

Answer 1

根据您提供的链接，他们并没有删除数据库优先设计，Code-First只是一个名称，表示您的数据库以一组POCO C#对象的形式表示，而不是XML +设计工具。

他们已经删除了设计器和.edmx文件。但是您仍然可以使用“反向工程”功能创建实体。

从该链接中：

对于Code First，您可以重新运行反向工程过程，并使其重新生成模型。这在基本场景中运作良好，但您必须小心自定义模型的方式，否则代码重新生成时将撤消您的更改。有一些定制很难应用，需要编辑脚手架代码。

他们删除设计器，使EF Code-First成为唯一选择，并不意味着您必须首先在C＃中创建实体，然后让它们生成数据库。所有这意味着是您的数据库将通过POCO映射，而不是.edmx。

相信我，.edmx +设计器只会带来麻烦！

如果您对反向工程结果或通过代码添加新表/关系不满意，那么我几乎可以肯定，某个人将创建一个花哨的拖放设计器作为第三方插件。但对于我和我认识的大多数开发人员来说，设计器只适合初学者，一旦您开始做某些事情或自定义它，您就可以通过注释+流畅的映射在代码中获得更好、更清洁、更易于理解的控制。

- Michal Ciechan

---

这在基本场景下运行良好，但是您必须小心如何自定义模型，否则当代码重新生成时，您的更改将被还原。我的观点是，Model First和Database First存在问题。但是他们没有修复它们，而是放弃了它们，迫使Code First成为EF首次推出时最糟糕的选择，并持续了相当长一段时间。显然，他们后来的努力集中在Code First上。问题在于当一个人进行转换、自定义，然后不能再从数据库更新模型而不失去自定义和视觉模型时。 - Dave

我猜你可能是那种抱怨 WPF 设计器没有 WinForms 设计器易用的人？其实这两个场景是相同的，如果有人除了查看视觉效果外，还在使用 WPF 设计器做其他复杂的事情，那么要么就是任务非常简单，要么就是用错了方法。 - Michal Ciechan

@Michael - 你还是那么傲慢吗？滚开——我不需要你无关的建议。在再次发表评论之前，你需要重新阅读我的问题。 - Dave

@michael - 我知道你可以将数据库反向工程到代码优先。你是否明白，这只能做一次，如果再次进行，就会失去自定义内容？或者我实际上需要一个设计师来帮助维护模型和关系，或者至少查看它们？ - Dave

@Dave，是的，我理解你的观点。我想这不是我喜欢的工作方式。最近我一直在使用代码迁移，而设计师在我们的一些项目中只会带来麻烦（由于初级开发人员从数据库更新时，有人正在测试内容，他们没有意识到自己提交了什么 :|）。 - Michal Ciechan