4

WCF サービスを介していくつかの CRUD 操作を行うアプリケーションを開発しています。read メソッドは完全なエンティティを返し、更新はレガシー システムを介して実行され、変更された値のみが更新されます。

キーと値のペアの辞書を送信するだけでなく、このシナリオのデータ コントラクトを設計する最善の方法は何ですか?

4

7 に答える 7

1

私が考えることができる他の唯一のことは、コンポーネントを耐久性のあるものにすることです。つまり、その状態をファイルまたはデータベースに保持します。そうすれば、更新時に、前の状態を渡された状態と比較できます。キーと値のペアを渡すよりも多くのオーバーヘッドが発生するため、これが適切な方法かどうかはわかりません。

外から見ると、もっと粗雑に見えるかもしれませんが、実用的な観点からは、どの値が変更されたかについての指示を渡すだけの方がよい場合があります。

于 2010-01-22T18:53:23.133 に答える
1

それが役立つ場合は、探しているものが正確にはわかりません...

更新リクエストでは、null ではないフィールドに対してのみ作用します。

さらに、null 非許容型を null 許容構造にラップします。

例として...

Update( Nullable<int> orderNumber, 
        Nullable<DateTime> orderDate, 
        Nullable<bool> isComplete )
{
    if( orderNumber != null )
        databaseRecord.OrderNumber = orderNumber;

    if( orderDate != null )
       databaseRecord.OrderDate = orderDate;

    if( isComplete != null )
       databaseRecord.IsComplete = isComplete;
}
于 2011-09-27T22:26:37.183 に答える
0

DataSet を使用して変更を保持できます。レコードを DataSet として呼び出し、いくつかの値をレコードに割り当てます。DataSet.Tables[0].GetChanges() は、変更された列を提供します。

于 2010-02-02T09:29:46.033 に答える
0

あなたの要件と声明を見て、可能な解決策について私のビジョンを書き始める前に、いくつかの仮定を立てました。

  • WCF サービスで、項目の取得 (「読み取り」操作の戻り値の型) と更新 (「更新」操作の入力パラメーターの型) に同じクラスを使用しています。
  • 現在の実装の問題は、元のクラス (辞書ではない) を使用する方法と、WCF サービスで呼び出された「更新」操作を取得したときに、「読み取りと比較して何が変更されたか」を判断できることです。
  • サーバーとクライアントの両方を作成しています。両方とも、MS .Net フレームワークを使用して作成されています。

これが当てはまる場合、問題は Update メソッドの欠落している情報にあります。必要な情報は 'has changed' です。これは、比較対象の 2 番目の状態が存在する場合、またはバックエンドで更新する状態と共に既に存在する必要がある場合に推測できます。

クライアントがそのデータを WCF サービスに投稿するときに「バックエンド状態」(フラグなし) しかないため、何が変更されたかをどのように判断すればよいでしょうか? 明らかに、現在のサーバーの状態を取得して比較を開始するために、別の「読み取り」ラウンドトリップを防止したいと考えています。

元の状態と変更された状態をクライアントからサーバーに送信することは可能ですが、重い解決策です。次に、この情報に関心があるのはクライアントではなく、サーバーです。

これをすべて足し合わせると、「更新」操作の入力パラメーターのタイプを変更するのが最も簡単な方法であると推測されます。元のエンティティに「ダーティ ビット」動作を追加するデコレータ クラスを作成します。この新しいクラスを「更新」操作の入力パラメーターとして使用します。その後、クライアントから送信された完全な状態の横にあるこのダーティ ビットをチェックするために、サーバーで可用性が得られます。クライアント側の主な変更点は、「更新」操作に必要なオブジェクトが、「読み取り」メソッドによって提供されるオブジェクトと同じではなくなったことです。この苦痛を軽減するために、必要な「ダーティ ビット」処理を追加するデコレータ クラスを作成することになるでしょう。これには、オブジェクトのインスタンス化を変更するだけで済み、クライアントのインターフェイス シグネチャは維持されます (コードの変更はほとんどありません)。

于 2010-02-05T19:26:13.687 に答える
0

これを実現する方法について 2 つのアイデアがありました。

  1. クライアントに元のエンティティと変更されたエンティティの両方を完全に送信させると、サービスは変更されたプロパティを特定します。

  2. Nullable に似たパターンを使用し、IsModified フラグと T 型の NewValue プロパティを使用して Modified と呼びましょう。DataContract の各プロパティはこの型になり、サービスは更新の実行時に IsModified フラグをチェックできます。

私たちが使用する従来のシステムには、変更されていないフィールドを識別するために String.Empty を受け入れる API があります。文字は、空の文字列への更新を示すために使用されます。私は本当にこれが好きではありません.APIのユーザーはドキュメントを読むことを余儀なくされています. できません。Web サービス API をより明示的にしたい。

于 2010-01-24T15:12:48.527 に答える
0

これを行う最善の方法は、プロパティ ディクショナリを使用することです。エンティティをプロパティ名と値のディクショナリとして表すだけです。すべての変更をいくつかのリストに保存し、変更されたすべてのプロパティを含む部分的な辞書を渡します。

ベストなデザインだと思いますが、

この設計を避けたい場合は、変更されたプロパティのリストを含むエンティティ全体を送信してください。(トランスポートを保存するために、他のプロパティに null を設定できます)

サービス契約の署名を変更したくない場合は、変更されたプロパティの名前をヘッダーにプッシュできます

于 2010-01-23T21:52:28.790 に答える
0

データ コントラクトをそのままにして、サービス コントラクトを更新できます。メソッドの必須フィールドをサービス コントラクト内のプロパティとして表すだけです。サービスの連絡先が変更された場合、サービスを使用するすべての消費アプリケーションを更新する必要がありますが、消費アプリケーションは、データを正常に更新するために何が必要かを認識しています。

このメソッドには長所と短所がありますが、私が書いているメソッドが完全なデータ コントラクトを必要としない場合に使用します。

-- 誤字脱字がありましたので修正 --

于 2010-02-04T02:29:45.960 に答える