流れるようなインターフェースは属性よりも柔軟性がありますか？

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で使用可能な機能のサブセットのみが含まれます。つまり、流れるようなAPIを使用してのみ実行できる特定のモデル構成があります。

たとえば、注釈を使用して指定できないものの一部を次に示します。

• DateTimeプロパティの精度
• 数値プロパティの精度とスケール
• 固定長としての文字列またはバイナリプロパティ
• 非UnicodeとしてのStringプロパティ
• 関係の削除時の動作
• 高度なマッピング戦略

個人的には、可能な限り検証関連のデータアノテーションを使用する傾向があります。MVCのような他のテクノロジーもこれらを利用できるからです。他のすべてについては、流れるようなAPIを好みます。

質問への回答はリンクに記載されています。

次に、このメソッド内でドメインに適用可能な制約をプログラムで定義します。

基本的に、属性よりもプログラムによるアプローチの方が多かれ少なかれ優先されます。プログラムによるアプローチでは、エンティティをより詳細に制御できます。ただし、モデルを装飾するために属性を追加するカスタムの方法もありますが、これも同様に見えます。

このアプローチを使用する場合、テーブルと列の間の関係を記述することもできます。結論として、ドメインをよりきめ細かく制御したい場合は、EF4.1に付属するこの新しいアプローチを使用できます。

ただし、検証の一般的なシナリオでは、属性の適用はほとんどの場合をカバーする堅牢なため、正常に機能するはずです。さらに、時間を節約できる可能性があります。

私は、データベースでリレーションシップがどのように作成されるかを明示的に説明しているため、コードファーストの実装には流れるようなAPIを推奨していると考えています。データ注釈を使用する場合、Entity Frameworkによって作成されたデータベースは期待したものとは異なる場合があります。最初の例は非常に単純なので、あなたと同じように、データ注釈メソッドを使用します。