web-dev-qa-db-ja.com

Entity Framework Code First-Fluent Apiとデータアノテーションの長所と短所

Entity Frameworkのコードファーストを使用してデータベースを作成する場合、多くのデータベースモデルをコードから抽出できます。 Fluent APIおよび/または属性を使用して、モデルを微調整できます。

データ注釈と比較したFluent Apiの長所と短所は何ですか？言い換えると、特定の状況で両方の方法を使用できる場合でも、どのような場合に一方の方法が他方よりも優先されるべきでしょうか？

entity-frameworkef-fluent-api
104
Sam

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を「高度な機能」と見なしています（ here からの引用）：

Fluent APIはより高度な機能と見なされるため、要件でFluent APIの使用が必要でない限り、Data Annotationsを使用することをお勧めします。

しかし、私の意見では、DataAnnotationsの制限にすぐに到達します（おそらく非常に単純なオブジェクトモデルを除く）。 DataAnnotationsを使用してモデルを微調整できない場合、最後の手段はデフォルトのマッピング規則に従うことです（これらのルールに従ってプロパティに名前を付ける）。現在、規則を上書きすることはできません（それらを無効にするだけです。MSは、将来のEFリリースで規則の構成オプションを提供することを発表しました）。しかし、オブジェクトモデルを定義するときにマッピング規則に強制されたくない場合、唯一のオプションはFluent APIです。

Fluent APIを学ぶことはほぼ必須です。DataAnnotationsは、単純なアプリケーションにとって便利です。

131
Slauma