与使用 Fluent API 手动指定所需属性相比，搭建现有数据库的脚手架有什么好处？

Question

我遇到了一个项目，其中原始开发人员通过仅指定必填字段及其导航属性来对 EF Core 中的实体进行编码。

如果我搭建现有的数据库表，我会得到服务器上表设计的完整定义;包括针对此特定应用程序不需要的其他字段的索引和关系。

与手动编写模型规范以仅指示必填字段及其导航属性相比，为所需表搭建脚手架有什么好处吗？

如果手动定义的模型省略了在服务器上为指定表定义的索引/检查约束的任何提及，这是否重要？

我使用 dbcontext cafold 命令对我需要的表进行逆向工程，但原始开发人员认为这效率不高。我倾向于认为，如果我包含服务器上存在的所有规范，查询性能会更好。

Note：此问题总结整理于:Benefits of scaffolding an existing database vs. manually specifying only the required properties using fluent API?

Answer 1

欢迎来到 Microsoft Q&A，我们需要根据某些特定情况决定使用现有数据库表的脚手架还是使用 Fluent API。

何时使用现有数据库表的基架：

a. 当您已经拥有现有的数据库表，并且需要它的所有索引和关系时

b.b. 当表包含许多字段，并且您不想为其创建模型类时。

c. 当您更喜欢使用数据库时，请设置一些字段而不是使用代码。

何时使用 Fluent API。

a.a. 当您没有现有的数据库表并且您已经编写了模型类时。

b.b. 当您拥有现有的数据库表，并且只想从数据库中指定较少的字段时。

c. 当您更喜欢使用代码来设置某些字段而不是使用数据库时。

像往常一样，这意味着如果使用 Fluent API，则在 ef core 中选择了代码优先方法。

总而言之，

如果你的所需属性计数不是太大，并且你更喜欢使用代码来设置这些属性，那么我建议你使用 Fluent API 来执行此操作。

如果你的所需属性计数太大，并且你对使用代码来指定这些属性感到麻烦，我建议你使用脚手架来做到这一点。

希望我的解释对您有所帮助。

此致敬意

千斤顶

---

如果答案是正确的解决方案，请点击“接受答案”并点赞。如果您对此答案有其他疑问，请点击“评论”。

注意：如果您想接收此线程的相关电子邮件通知，请按照我们文档中的步骤启用电子邮件通知。