質問

私は以下の印象を受けています

  • EF with POCO:独自のPOCOをモデル(.edmx)のエンティティにマッピングできます。
  • EFコードのみ:edmx /モデルデザイナー(つまり、CSDL / SSDL / MSL(総称してEDMX)メタデータ)。まだPOCOですが、マッピング、関係、ナビゲーションなどはすべて手動でコーディングされています(したがって、コードのみ、説明です)。

この2つの概念の説明が(多かれ少なかれ)正しい場合、なぜ誰かがEFの代わりにPOCOを使用してコードのみを実行するのでしょうか?

どちらもPOCOを行っていますが、2番目のマッピングには手動でマッピングを行う必要があるという余分な負担がありますか?

役に立ちましたか?

解決

  1. XMLを使用せずに手動でマッピングを記述したい場合にのみ、コードは素晴らしいです。また、edmxデザイナーは、50個ほどのモデルの後に扱いにくくなります。その方法を使用するのは負担です。

マッピングXML内で何か問題が発生した場合、実際にPITAでXMLを掘り下げて必要な修正を行います。また、特定のシナリオでxmlの手動編集を開始すると、デザイナーが壊れます。

詳細はわかりませんが、EF1のデザイナーは利用可能なすべてのマッピングオプションをサポートしていませんでした。 EF4デザイナーにはいくつかの改善点があります(一方通行の関係が思い浮かびます)が、手動マッピングと同等の機能を備えているかどうかはわかりません。

  1. はい。

他のヒント

jfarの答えに追加する唯一のことは、Code-Onlyではマッピングを作成する必要がないことです。

マッピングは、ほとんどの場合、慣例により推測できます。

ビューの事前生成に関するポイントは重要です。 Microsoftには、コードのみの事前生成を提供する意図があるとは聞いていません。誰かが違うことを知っているなら、投稿してください。

EF4またはNHibernateを使用するかどうかの調査の一環として400テーブルに対してコードのみを使用しましたが、ビュー生成には80秒の初期遅延があります-デザイナーを使用する場合とまったく同じですが、デザイナービューの事前生成が可能で、遅延が10秒に短縮されました。モデルの分割に満足できず、約75を超えるテーブルがある場合は、コードのみにしないでください。

現在、Code-Onlyではビューを事前生成できるとは思わないため、パフォーマンスコストが発生する可能性があります。ただし、リリース前に変更される可能性があります。

言及されていない他のことは、コードのみを使用する場合、構文の完全なコンパイル時チェックを取得することです。 EDMXでビジュアルデザイナーを使用している場合、コンパイル時のチェックが行われますが、制限があります。大きなモデルの場合、EDMXは非常に扱いにくくなり、CSDL、SSDL、およびMSLを手動で記述することは、XMLマッピングを使用して非常に大きなモデルを管理する唯一の適切な方法です。マッピングを手動で管理する場合、コンパイル時のチェックは行われません。

コードのみを使用すると、操作する必要のあるエンティティが数百または数千ある場合でも、あらゆるサイズのモデルを完全にコンパイル時にチェックできるという利点があります。また、アセンブリとさまざまな種類のxmlファイルが混在するのではなく、最終製品がすべてコンパイルされたアセンブリであるため、「クラッター」が少なくなります。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top