8

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

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

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

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

编辑

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

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

感谢您的帮助

4

3 回答 3

9

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

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

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

喜欢 Fluent API 的原因

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

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

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

编辑：根据问题编辑，

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

于 2012-05-22T21:11:52.967 回答
4

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

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

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

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

于 2012-05-22T21:08:54.913 回答
1

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

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

于 2012-05-22T21:07:07.133 回答