流利的接口比属性更灵活吗？为什么？

在EF 4.1 Code First教程中，给出了以下代码：

public class Department
{
    public int DepartmentId { get; set; }
    [Required]
    public string Name { get; set; }
    public virtual ICollection<Collaborator> Collaborators { get; set; }
}

然后说明了流畅的界面更加灵活：

数据批注绝对易于使用，但是最好使用编程方法来提供更大的灵活性。

然后给出使用流畅接口的示例：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Department>().Property(dp => dp.Name).IsRequired();
    modelBuilder.Entity<Manager>().HasKey(ma => ma.ManagerCode);
    modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .IsConcurrencyToken(true)
        .IsVariableLength()
        .HasMaxLength(20);
}

我不明白为什么据说流畅的界面会更好。真假的啊？从我的角度来看，数据注释看起来更加清晰，并且具有更清晰的语义感觉。

我的问题是，为什么流畅的界面会比使用属性更好的选择，尤其是在这种情况下？

（注意：我对流畅接口的整体概念还很陌生，所以请不要对此有所了解。）

参考：http : //codefirst.codeplex.com/

数据注释是静态的，例如，此方法声明不能在运行时更改：

  [MinLength(5)]
  [MaxLength(20,ErrorMessage="Le nom ne peut pas avoir plus de 20 caractères")]
  public new string Name { get; set; }

流利的界面可以是动态的：

   if (longNamesEnabled)
   {
      modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .HasMaxLength(100);
   }
   else
   {
      modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .HasMaxLength(20);
   }

更不用说代码可以在属性之间重用。

我认为该声明不应广泛适用；它对于Code First非常特定。在Code First中，数据批注仅包含fluent API中可用功能的一部分。换句话说，某些模型配置只能使用Fluent API来完成。

例如，以下是一些无法使用注释指定的内容：

• DateTime属性的精度
• 数值属性的精度和小数位数
• 固定长度的String或Binary属性
• String属性为非unicode
• 关系的删除行为
• 先进的制图策略

就我个人而言，我倾向于尽可能使用与验证相关的数据注释，因为其他技术（例如MVC）也可以利用这些注释。对于其他所有方面，我更喜欢流畅的API。

链接中提供了您问题的答案。

然后，以编程方式在此方法中定义适用于您的域的约束。

基本上，相对于程序设计方法而言，或多或少地倾向于使用“属性”而非“程序设计方法”，因为程序设计方法对实体具有更多的控制权。但是，有一种添加属性以装饰模型的自定义方式，您可能也会看到它。

使用这种方法时，您甚至可以描述表和列之间的关系。底线是，如果您希望对您的域进行更细粒度的控制，则可以使用EF4.1随附的这种新方法。

但是，对于验证的常见情况，应用属性应该可以正常工作，因为它可以覆盖大多数情况。另外，它可以节省您的时间。

我的想法是，他们建议使用流利的API进行代码优先实现，因为您明确描述了如何在数据库中创建关系。如果使用数据批注，则可能不是由Entity Framework创建的数据库。您最初的示例非常简单，因此像您一样，我将只使用数据注释方法。