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

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在我的数据上下文类中对该方法进行验证.

您无法使用Data Annotations方式执行所有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.