Entity Frameworkをコードファーストで使用してデータベースを作成する場合、データベースモデルの多くをコードから抽出できます。Fluent APIや属性を使用して、モデルを微調整できます。
データアノテーションと比較したFluent Apiの長所と短所は何ですか?つまり、特定の状況で両方の方法を使用できる場合でも、どの方法で一方の方法が他方よりも優先されるのでしょうか。
Entity Frameworkをコードファーストで使用してデータベースを作成する場合、データベースモデルの多くをコードから抽出できます。Fluent APIや属性を使用して、モデルを微調整できます。
データアノテーションと比較したFluent Apiの長所と短所は何ですか?つまり、特定の状況で両方の方法を使用できる場合でも、どの方法で一方の方法が他方よりも優先されるのでしょうか。
回答:
DataAnnotationsで構成できるすべてのことは、Fluent APIでも可能です。逆は当てはまりません。そのため、構成オプションと柔軟性の観点から、Fluent APIは「優れています」。
Fluent APIで可能ですが(私が見る限り)DataAnnotationsでは不可能である構成例(確かに完全なリストではありません):
カスケード削除をオフにします。
.WillCascadeOnDelete(false)
オブジェクトモデルでキーが公開されていない場合は、データベースに外部キー列名を指定します。
.Map(conf => conf.MapKey("MyForeignKeyID"))
関係の細かい調整、特に、関連付けの片側のみがオブジェクトモデルで公開されるすべての場合。
.WithMany(...)
、WithOptional(...)
、WithRequiredDependent(...)
、WithRequiredPrincipal(...)
オブジェクトモデルとデータベーステーブルの間の継承マッピングの仕様(Table-Per-Hierarchy、Table-Per-Type、Table-Per-Concrete-Class):
.Map<TDerived>(Action<EntityMappingConfiguration<TDerived>> ...)
編集:MicrosoftはFluent APIを「高度な機能」と見なしています(ここからの引用):
Fluent APIはより高度な機能と考えられており、Fluent APIを使用する必要がある場合を除き、データアノテーションを使用することをお勧めします。
しかし、私の意見では、DataAnnotationsの制限にすぐに到達します(おそらく非常に単純なオブジェクトモデルを除く)。DataAnnotationsを使用してモデルを微調整できない場合、最後の手段は、デフォルトのマッピング規則に従うことです(これらの規則に従ってプロパティに名前を付けることにより)。現在、規則を上書きすることはできません(無効にするだけです。MSは、今後のEFリリースで規則の構成オプションを提供することを発表しました)。ただし、オブジェクトモデルを定義するときにマッピング規則に強制されたくない場合、唯一の選択肢はFluent APIです。
Fluent APIを学ぶことはほぼ必見ですが、DataAnnotationsは単純なアプリケーションにとって便利です。
[Required]
ASP.NET MVCアプリケーションのプロパティに属性を配置すると、EF と MVCの両方がこの属性を処理できるため、検証目的で使用されます。しかし、MVCはFluent API構成を理解しません。したがって、属性を削除してHasRequired
代わりにFluent APIで使用すると、EFの場合は同じになりますが、MVCの場合は異なります。(私の意見では、属性には異なる名前を付ける必要がありました。異なるコンポーネントからのDataAnnotations名前空間の使用は、異なる目的のために非常に混乱しています。)
[DefaultValue()]
、Fluent Eitherでは使用できません。
Fluent API
、実装ロジックDbContext
を維持し、POCO
クリーンな状態を維持すると思います