WebApi と EF POCO は非常にうまく連携します。私が考えている問題は、一部のオブジェクトは時間の経過とともに非常に大きくなる可能性があるということです。データベース内の列にマップする多くのプロパティを持つことができます。これらのオブジェクトを使用すると、一度に 1 つまたは 2 つ以上のフィールドを更新することはめったにないため、なぜすべてのフィールドがクライアントからサーバー、データベースへと完全に戻る必要があるのかという疑問が生じます。
一部の JavaScript フレームワークでは、すべてのフィールドを送信するか、変更されたフィールドのみをサーバーに送信するかを選択できるオプションが提供されているため、クライアント側はクリーンでシンプルです。
サーバー側は、私が見たところ、もう少し難しいものです。シリアライザーが介入し、json または xml を型にマップしようとします。たとえば、JSON.NET は、オブジェクト内の対応するプロパティが null 許容であれば、欠損値を適切に処理します。
一方、逆シリアル化されたモデルをエンティティ フレームワークに再アタッチするのは、ややこしいところです。コントローラーのデフォルトの WebApi テンプレートは、1 行でそれを行います。
db.Entry(user).State = EntityState.Modified;
これは明らかにオブジェクト全体を変更済みに設定します。もちろん、オブジェクト全体ではなく個々のプロパティを変更済みに設定することは可能です。これは、EF がもう少し賢く、SQL UPDATE で変更されたプロパティのみを送信することを意味すると思います。
ここでの問題は、更新されたプロパティをどのように知ることができるかということです。コントローラーメソッドでオブジェクトを取得するだけなので、シリアライザーに取得したプロパティを尋ねることはできません (特定のシリアライザーで可能であったとしても)。プロパティのリストがある場合、現在の値を EF で変更された状態に設定でき、うまくいけば、クリーンな db クエリが得られるはずです。
もう1つのおそらくより明白なオプションは、最初に更新したいオブジェクトをデータベースから取得し、取得したオブジェクトで変更されたプロパティのみを1つずつ変更することです。または、EFがそれをサポートしている場合は、添付されていないオブジェクトを渡すことができます。それを自分でやらせます。これは、演習の全体的なポイントが効率である場合にデータベース全体を読み取ることを意味するため、望ましいオプションではありません。私たちがやっていることは、クライアントの http の効率と帯域幅を、サーバーでのヒットと db の効率で交換することです。
したがって、サーバーでこれを実行したい場合、私は岩と困難な場所の間にいるようです。WebApi と EF がほとんどの作業を行いますが、柔軟性が犠牲になります。これら 2 つの優れたテクノロジのいずれかを無駄にしないシンプルなソリューションを期待して、言及していないオプションや角度を探しています。