web-dev-qa-db-ja.com

流暢なインターフェイスは属性よりも柔軟性がありますか？その理由は？

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/

c#coding-style
15
Tjaart

データアノテーションは静的です。たとえば、このメソッド宣言は実行時に変更できません。

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

Fluentインターフェイスは動的にすることができます。

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

言うまでもなく、コードはプロパティ間で再利用できます。

13
Garrett Hall

私はそのステートメントが広く適用されるべきではないと思います。これは、Code Firstに固有のものです。 Code Firstでは、データアノテーションには、Fluent APIで使用可能な機能のサブセットのみが含まれています。つまり、Fluent APIを使用してのみ実行できる特定のモデル構成があります。

たとえば、アノテーションを使用して指定できないものは次のとおりです。

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

個人的には、MVCなどの他のテクノロジーでもこれらを利用できるため、可能な限り検証関連のデータ注釈を使用する傾向があります。それ以外はすべて、流れるようなAPIを好みます。

8
bricelam

質問への回答はリンクにあります。

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

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

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

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

1
Yusubov

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

0
str8killinit