代码优先：fluent api 会影响 UI 吗？

Question

我正在阅读 Julie Lerman 撰写的关于 Code First 的书。根据这本书，注释和流利的 api 给出了相同的结果。一切都取决于开发者的风格。

我知道注释允许配置代码首先如何生成数据库对象以及 MVC 如何自定义 UI 元素。假设我使用 [Required, MaxLength(50)]。该属性将在数据库中生成一个 NOT NULL，nvarchar (50)。它还将验证该字段的输入。

[Required, MaxLength(50)]
public string Name { get; set; }

如果我决定先使用 Fluent API 配置代码会怎样。我仍然需要注释来影响 UI 元素还是使用流畅的 API 就足够了？

编辑

注释（例如仅用于 UI 目的的 Display）呢？他们有等价物吗？如果没有，我需要使用注释吗？

[Display(Name = "Date of Birth")]
public DateTime BirthDate { get; set; }

感谢您的帮助

Answer 1

根据 Julie Lerman 关于 DbContext 的书，您不需要对 Fluent API 配置进行任何额外的注释。 Name 属性将由 Validation API 进行验证，就好像它已经配置了数据注释一样。

根据同一本书，MaxLength 和Required 是唯一具有流畅API 关系的验证属性。

Answer 2

数据注释是告诉类强制执行某些验证规则的最简单方法。你也可以用 Fluent API 做同样的事情。有些人喜欢通过数据注释来做，有些人喜欢用流畅的 API 来做

使用数据注释喜欢它的原因

1) 将有关我的实体的验证信息与实体定义一起保存在一个地方

喜欢 Fluent API 的原因

1) 保持我的实体干净。它将只有我的财产信息。没有验证信息。干净简单的 POCO。我将在我的数据上下文类中对OnModelCreating 方法进行验证。

你不能用数据注释的方式做所有的 Fluent API 事情。与 Fluent API 方式（例如：HasMinLength）不存在等效的数据注释属性相同。 HasMinLength 是我们用于模型验证的东西，通常在 UI 中是有意义的。

对于 UI 模型验证，您不能单独使用 Fluent API。 Fluent API 的主要作用是查看我们编写的流畅配置，并在从实体创建模型（数据库）时采取行动。 请记住，我们正在重写 OnModelCreating 方法来编写流畅的 API 配置。因此，对于（我的 ViewModel 的）UI 验证，如果我想定义与我的数据模型相关的一些东西，例如定义外键或将此实体映射到具有不同名称的表等，我将使用 DataAnnotation 方式并使用流畅的 API。

编辑：根据问题编辑，

在这种情况下，您应该使用数据注释。如果你先做代码。您可能还记得该实体将成为您的数据库表（当然您可以告诉 EF 忽略/重命名特定列）。在这种情况下，我会保持我的Entities 干净并创建一个ViewModel，我将在我的用户界面中使用它。我将在我的ViewModel 中添加我的DataAnnotations 来处理它。我可能会编写一些映射代码，在必要时将数据从 ViewModel 映射到 Model 和 Model 到 ViewModel。

Answer 3

如果您的实体模型类是视图模型类的两倍，并且您使用的是开箱即​​用的默认 DataAnnotationsValidationProvider，那么您将需要模型属性上的 dataannotations 属性来获得验证。

但是，您不应该将您的实体类加倍为视图模型类。例如，需要在其模型中具有 ReturnUrl 属性的控制器。您不希望在您的实体模型/数据库中使用它。由于 View 模型和 Entity 模型之间存在这样的差异，因此这两个模型在您的应用程序中应该是独立的（但有凝聚力的）层。您可以使用 AutoMapper 之类的库使它们具有凝聚力。

这是我更喜欢 fluent API 的原因之一。如果您坚持使用 fluent API，那么您将永远不会在任何实体模型类或属性上放置任何属性。当需要显示、插入或更新数据时，您只将属性放在视图模型类上。

此外，实体类型上的 [Required] 属性在 SaveChanges 期间执行验证，而视图模型上的 [Required] 属性在模型绑定期间执行验证。