6

POCO がサーバー側の Entity Framework によって取り込まれ、クライアント アプリケーションに転送される N 層アプリケーションがあります。クライアントは、POCO に変更を加えるか、新しい POCO を追加してから、それらをサーバーに送り返してデータベースに保存します。

純粋な POCO を使用している場合、つまりプロキシも自己追跡エンティティも使用していない場合、変更追跡の問題を解決するために人々が取っている一般的なアプローチにはどのようなものがありますか? サービスが POCO のコレクションを受け取る場合、Entity Framework を使用して追加、更新、または削除を行うことをどのように認識しますか?

4

1 に答える 1

6

Entity Framework には、このような切断されたシナリオに対する適切なサポートが組み込まれていません。私は、次の 3 つの一般的なオプションを認識しています。

  • オープンソースのアドオン ライブラリであるGraphDiffを使用する

    利点

    • クライアント側で変更追跡コードを記述する必要はありません
    • データベース内の切断されたオブジェクト グラフを更新する一般的なパターン
    • サーバー側に書くコードが少ない


    短所

    • オブジェクトを追加、更新、または削除する必要があるかどうかを検出するには、データベースにクエリを実行し、エンティティをロードする必要があります
    • EF コア ライブラリに加えて、サード パーティのライブラリへの依存


  • サーバー側でオブジェクト グラフを手動で更新する (例)

    利点

    • クライアント側で変更追跡コードを記述する必要はありません
    • EF コア ライブラリに加えて、サード パーティのライブラリに依存しない


    短所

    • オブジェクトを追加、更新、または削除する必要があるかどうかを検出するには、データベースにクエリを実行し、エンティティをロードする必要があります
    • 一般的なパターンはありません。つまり、ほとんどの更新シナリオでは個別のコードが必要です
    • サーバーサイドで書くコードが多い


  • エンティティの状態のプロパティをオブジェクトに追加し、それに応じて状態を設定して、クライアント側で変更を手動で追跡します (このアプローチの例はありません。Julie Lerman が使用し、推奨していると思います)。

    利点

    • オブジェクトを追加、更新、または削除する必要があるかどうかを検出するためにデータベースを照会する必要はありません
    • EF コア ライブラリに加えて、サード パーティのライブラリに依存しない
    • (おそらく?) 追跡された状態を接続されたエンティティのエンティティ状態に変換するためのサーバー側の一般的なパターン


    短所

    • トラッキング コードをクライアント側で書き込むように変更する
    • クライアント側に共通のパターンがない。つまり、ほとんどの変更追跡シナリオ (およびクライアントの種類/UI テクノロジ) には個別のコードが必要
于 2013-09-27T22:16:33.083 に答える