如果没有弄错的话，Fluent api中qazxsw poi的数据注释的反对部分是qazxsw poi。
那么qazxsw poi的对应部分是什么？
或者是否有一个网站，其中包含一个“你可以做的数据 - 注释”列表 - 你可以用它做一个流利的API。因为我想使用Fluent Api进行验证和映射。谢谢
这是一个众所周知的混乱区域。
关于你的例子：
[DataType(DataType.Currency)]注释的属性实现为modelBuilder.Entity<T>.Property(i => i.Price).HasColumnType("Currency")（在Sql Server中）。关。[DataType(DataType.EmaillAddress)]（不是“货币”）将列创建为[DataType(DataType.Currency)]数据类型。一场精彩的比赛。decimal(18,2)注释的字符串属性将创建为HasColumnType("Money")。当然，这足以用于电子邮件地址。但它远不是一种强制执行特定格式的数据类型。当然EF可以做得更好，不是吗？那么，在后一种情况下，它该怎么办？没有内置的电子邮件数据类型，我认为我们不能指望EF使用规则和所有动态创建用户定义的类型（更不用说Sql Server中的规则已被弃用）。
令人困惑的部分是数据注释被不同的框架使用不同，如Money所解释的那样。
我不确定EF团队是否通过在代码优先实现一部分注释做出了正确的决定。当然，它们无法在广泛的System.ComponentModel.DataAnnotations命名空间中实现所有属性。但目前的实施充其量只是半心半意。上面的例子只是一个小例子 - 一个注释被实现，另一个没有。而且，就此而言，EF很乐意允许您将[DataType(DataType.EmailAddress)]属性注释为nvarchar(max)。
因此，回答你的问题，here没有流利的对应物。没有什么可以对应的。
另一方面，为了说出EF，根本没有实现注释会迫使我们做多余的事情。如果我们一起使用MVC和EF，注释可以应用一次，两个系统都很好地兼容。使注释和流畅的配置匹配将是一项繁琐的工作。
不幸的是，我找不到任何披露注释和流畅API之间完整映射的来源。也许这是最糟糕的部分：我们必须通过反复试验找出答案。有谁在那里开导我们？
我认为你的第一个例子是巧合，int注释用于指定更合适的CLR类型。与数据库完全无关，因为它也可以在序列化时使用
EmailAddress显然适用于数据库，我认为这是因为EF做出错误的选择，节省空间的问题，或者您将自己的自定义类型添加到数据库中。
在我自己的工作中，我已经遵循了我可以使用注释的规则，只要它们在DataType.EmailAddress命名空间中，其他任何东西（可能是EF特定的）都是通过Fluent完成的，因为这些更容易改变如果使用不同的ORM。