实体框架代码优先 - Fluent Api 与数据注释的优缺点 [关闭]

Posted 2023-03-31

【中文标题】实体框架代码优先 - Fluent Api 与数据注释的优缺点 [关闭]

【英文标题】：Entity Framework Code First - Advantages and disadvantages of Fluent Api vs Data Annotations [closed]

【发布时间】：2011-07-18 07:33:18

【问题描述】：

使用 Entity Framework 代码优先创建数据库时，可以从代码中提取很多数据库模型。 Fluent API 和/或属性可用于微调模型。

Fluent Api 与 Data Annotations 相比有哪些优缺点？换句话说：即使在某些情况下两种方法都可以使用，在什么情况下一种方法应该优于另一种方法？

【问题讨论】：

只是一个想法：我通常做的是用我的 POCO 创建一个 Model 项目，然后在 Repository 项目中，专门为 EF 创建一组新的 POCO，并将我的注释放在那里。然后我只是在映射器类中映射两者。这样，我的模型保持不变，并且可以在必要时轻松添加/更改我的数据策略（例如，添加 XmlRepository 并使用相同的模型类）。

我现在更喜欢 Annotation，带有 EFCore 和其他库。 （需要更少的代码，并且都在一个地方）github.com/isukces/EfCore.Shaman - 添加和扩展属性 github.com/borisdj/EFCore.FluentApiToAnnotation - 在数据库已经存在时很有用，在进行逆向工程并切换到 CodeFirst 之后

【参考方案1】：

您可以使用 DataAnnotations 配置的所有内容也可以使用 Fluent API 进行。反过来是不正确的。因此，从配置选项和灵活性的角度来看，Fluent API “更好”。

Fluent API 中可能的配置示例（肯定不是完整列表）但不能使用 DataAnnotations（据我所知）：

关闭级联删除：

.WillCascadeOnDelete(false)

在对象模型中未公开键时指定数据库中的外键列名：

.Map(conf => conf.MapKey("MyForeignKeyID"))

关系的细粒度调整，尤其是在对象模型中只暴露关联的一侧的所有情况下：

.WithMany(...)、WithOptional(...)、WithRequiredDependent(...)、WithRequiredPrincipal(...)

对象模型和数据库表之间的继承映射规范（Table-Per-Hierarchy、Table-Per-Type、Table-Per-Concrete-Class）：

.Map<TDerived>(Action<EntityMappingConfiguration<TDerived>> ...)

编辑：微软将 Fluent API 视为“高级功能”（引自here）：

fluent API 被认为是一个更 高级功能，我们会 推荐使用数据注解 除非你的要求要求你 使用流畅的 API。

但在我看来，您很快就会达到 DataAnnotations 的限制（可能除了极其简单的对象模型）。如果您不能再使用 DataAnnotations 微调您的模型，您最后的手段是遵循默认映射约定（通过根据这些规则命名您的属性）。目前您无法覆盖约定（只能禁用它们；MS 宣布在未来的 EF 版本中为约定提供配置选项）。但是，如果您不想在定义对象模型时受到映射约定的约束，那么您唯一的选择就是 Fluent API。

学习 Fluent API 几乎是必须的恕我直言，DataAnnotations 是简单应用程序的必备工具。

【讨论】：

@CounterTerrorist：我不这么认为。例如：如果您将[Required] 属性放在 ASP.NET MVC 应用程序中的属性上，EF 和 都将使用该属性进行验证，因为两者都可以处理此属性。但是 MVC 不会理解 Fluent API 配置。因此，如果您删除该属性并在 Fluent API 中改用 HasRequired，对于 EF 它将是相同的，但对于 MVC 则不同。 （在我看来，属性应该有不同的命名，来自不同组件和不同目的的 DataAnnotations 命名空间的使用非常令人困惑。）

另请注意 [DefaultValue()] 在 Fluent Either 中是不可能的。

MinValue 是无法通过 Fluent API 定义的属性（编程实体框架：代码优先）（来源：The Cog 删除的 NAA）

从架构的角度来看，我猜Fluent API 会将您的实现逻辑保留在您的DbContext 中并保持您的POCOs 干净

属性的优点是每个实体都将每个属性的设置封装在该实体本身内。超级干净，让 .sql 脚本正式设计您的数据库并使用属性对类文件进行逆向工程；也绕过迁移。