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(Name = "Date of Birth")]
public DateTime BirthDate { get; set; }

感谢您的帮助

Answer 1

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

来做

使用数据注释的原因

1）将有关我的实体的验证信息与实体定义

一起保存在一个位置

使用Fluent API的原因

1）保持我的实体清洁。它只有我的房产信息。没有验证信息。干净简单的POCO。我将在我的数据上下文类中的OnModelCreating方法上编写验证。

您无法使用数据注释方式执行所有Fluent API操作。与Fluent API方式（Ex：HasMinLength）不存在的数据注释属性相同的方式相同。 HasMinLength是我们用于模型验证的东西，通常在UI中有意义。

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

编辑：根据问题编辑，

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

Answer 2

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

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

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

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

Answer 3

根据Julie Lerman关于DbContext的书，您不需要为Fluent API配置添加任何其他注释。 Name属性将由Validation API验证，就像它已使用Data Annotations配置一样。

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

代码优先：流畅的api会影响用户界面吗？

3 个答案: