0

シナリオ: データ モデルのエンティティがさまざまな情報と共に WCF Web サービスに渡され、データベースに保存された後、追加情報が完全に入力されたオブジェクトが返されます。

   public class Request
   {
    public virtual Guid RequestID { get; set; }
    public virtual string RequestType { get; set; }
    public virtual System.DateTime CreatedDate { get; set; }
    //More properties here populated from DB
   }

   [OperationContract]
   Request CreateRequest(Request input);

この例では、RequestID と CreatedDate は、レコードがデータベースに挿入されたときにのみ入力されるため、最初の要求時には表示されません。ただし、オブジェクトが返されたときに表示されるはずです。

現在行っているアプローチは、エンティティから継承する Web サービス実装プロジェクトで 2 つのクラス (RequestInput、RequestOutput) を作成することです。次に、必要なさまざまなプロパティに [DataMember] 属性を追加し、無視する必要があるプロパティに [IgnoreDataMember] 属性を追加します。

これは正しいアプローチですか？

4

1 に答える 1

1

それが正しい、または間違った方法であるとは言いません。しかし、次のような名前を使用するのがより一般的です

[DataContract]
Request{...}

と

[DataContract]
Response{...}

リクエストとレスポンスは、理想的には、クライアントとサーバーで使用しているモデル表現から分離する必要があります。つまり、サービス コードからモデルにマップするファサードまたはアダプターがあります。

これは私が行う方法に沿ったものですが、これはエンティティのサイズなどに依存する非常に主観的なものです.何らかの方法で自動マッパーを使用したい場合があります.

// higher level code
var entity = new Entity { properties we know before call };
// pass down to service layer 
var response = service.CreateRequest(new Request { Prop1 = entity.Prop1... } );
entity.RequestID = response.RequestId;
entity.CreatedDate = response.CreatedDate;
于 2012-02-22T13:16:03.703 に答える