0

Scenario: An entity from data model is passed into a WCF Web Service with various information, saved into a database and then returned back with the object fully populated with additional information. 

   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);

In this example, the RequestID and CreatedDate are populated only when the record is inserted into the database, and therefore should not be visible during the initial request. They should be visible when the object is returned however.

The current approach that we are going with is to create two classes (RequestInput, RequestOutput) in our web service implementation project which inherit from the entity. We will then add [DataMember] attributes on various properties that are required and [IgnoreDataMember] on those that should be ignored.

Is this the correct approach?

Damien Dennehy
  • 3,937
  • 2
  • 19
  • 21

1 Answers1

1

I wouldn't say it is a correct or incorrect way. But it is more usual to use names something along the line of 

[DataContract]
Request{...}

and 

[DataContract]
Response{...}

the Request and Response should ideally be decoupled from the model representation you are using in the client and the server - ie you have a facade or adaptor that maps them to your model from your service code.

this is along the lines of how I would do it - but this is very subjective dependant on size of entities etc - you may want to involve an auto-mapper somehow.

// 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;
dice
  • 2,820
  • 1
  • 23
  • 34
  • We initially did discuss decoupling it, but the additional mappings from the web service Request object to the model Request object seemed to bring up some duplication of code. – Damien Dennehy Feb 22 '12 at 13:24