John Pappa の多視野トレーニング ビデオを見終わったところですが、すべての要素がどのように組み合わされているかに感銘を受けました。
学んだことを消化していると、深刻な考えが残ります。
非常に簡単な方法でデータ サービスのクエリ可能な部分と CUD 部分を作成するため、CUD 部分には独自の webapi メソッド シグネチャが多すぎるようです。使い方は簡単で、そのシンプルさゆえに優れた機能を備えていますが、CUD の部分で Post、Put、および Delete に慣れています。これらの個々の WepApi メソッドはコーディングが必要ですが、物事を保存するための明示的に記述されたロジックを許可します。たとえば、私は論理的な削除のみを行うため、明示的に宣言された Delete webapi 関数を使用すると、削除されたレコードを監査テーブルに挿入し、DeletedDate を設定してレコードを削除済みとしてマークし、実際にはレコードを削除しません。場合によっては、その人の役割に基づいて、オーバーポスティング保護を行いたいことがあります。たとえば、CreatedDate はエンティティのプロパティである可能性がありますが、そのプロパティのクライアント側の強制的/無効な変更は、サーバー側の列を自動更新するべきではありません。または、ServiceTicket エンティティの一部である間、割り当てられたサービス技術者は、ユーザーが特定の役割を持っていない限り、クライアントが更新できないようにする必要があります。
これらのサーバー側の介入は、SaveChanges メソッドのどこで、どのようにコード化できますか? そして、人々が「api」のような完全な Post/Put/Delete を期待し、そよ風が SaveChanges のような単一のメソッドしか提供しない場合はどうなるでしょうか?
そして最後に、odata 実装がまだ展開と選択を行っていないため、そよ風が独自の ContextProvider のみを使用していると思いますよね? wepapi odata がすべての odata 動詞を完全に実装した場合、その余分なレイヤーを廃止する計画はありますか? 2012 Update 2 では、この点に関してどのように変更されましたか?
ありがとう