19

ドメイン オブジェクトをあらゆる種類の永続化コードから完全に分離できるため、システムの拡張性と保守性が大幅に向上します。ビジネス ロジックをストレージ コードとは別にテストできると、テストがはるかに簡単になります。Entity Framework (EF) での POCO の使用は、間違いなく正しい方向への一歩です:)

EF での poco の使用には、2 つのタイプがあります。 1.エンティティ デザイナーを使用する 2.コードのみを使用する

エンティティ データ モデル デザイナーを使用した EF poco コードまたは EF Poco のどちらが最善のアプローチですか?

ありがとう

4

1 に答える 1

18

それは選択の問題です。

デザイナーによる EFv4

長所：

  • エンティティを生成するデザイナー サポートと T4 テンプレートを利用できます = RAD。
  • ビュー、ストアド プロシージャ マッピング、QueryView やモデル定義関数などのカスタム モデル定義オブジェクトのサポートを含む非常に大きな機能セットがあります。
  • 必要に応じて他の EF 型をサポートします (自己追跡エンティティ、エンティティ オブジェクト)。

短所：

  • デザイナーは、大きなモデル (50 以上のテーブル) にはあまり適していません。
  • すべての機能がデザイナーでサポートされているわけではありません - XML として EDMX にアクセスする必要があります
  • EDMX XML 構造は、利用可能なすべての .NET ORM ツールの中でおそらく最も複雑で理解しにくい記述です。
  • デザイナーと共有環境で作業するのは面倒です - EDMX で排他ロックを使用することをお勧めします
  • 編集：非常に人気のある欠点を忘れていました。Designer は、ダイアグラム内のエンティティの配置に関する独自のデータとともに、すべてのマッピング データを EDMX に保存します。ダイアグラムのズームなどの愚かなアクションでさえ、ソース管理から EDMX ファイルをチェックアウトします。

最初にEFコード

長所：

  • コードですべてを定義する機能
  • 属性ベースのマッピングと Fluent API
  • いくつかの非常に優れた API 機能 - 規則、ローカルなど。
  • この API はそれほど複雑ではなく、使いやすいと思います

短所：

  • まだ最終リリースではありません。現在のリリースはコミュニティ テクノロジー プレビュー 5 のみです。
  • そのため、API は最終リリースで変更される可能性があります。
  • すべてのコードを自分で作成する必要があります。
  • 「大きな」EF に比べて、機能セットは限られています。
  • ドキュメントはありません。現在、ブログで情報を探す必要があります。

現在、私は最初のアプローチを使用しています。最終リリース後は、まずコードに満足するでしょう。

于 2011-02-23T10:05:36.330 に答える