Question

Scénario: une entité du modèle de données est transmise à un service Web WCF avec diverses informations, enregistrée dans une base de données, puis renvoyée avec l'objet entièrement rempli d'informations supplémentaires.

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

Dans cet exemple, RequestID et CreatedDate sont renseignés uniquement lorsque l'enregistrement est inséré dans la base de données et ne doivent donc pas être visibles lors de la requête initiale.Cependant, ils doivent être visibles lorsque l'objet est renvoyé.

L'approche actuelle que nous utilisons consiste à créer deux classes (RequestInput, RequestOutput) dans notre projet d'implémentation de service Web qui héritent de l'entité. Nous ajouterons ensuite des attributs [DataMember] sur diverses propriétés requises et [IgnoreDataMember] sur celles qui doivent être ignorées.

Est-ce la bonne approche?

Était-ce utile?

La solution

Je ne dirais pas que c'est une manière correcte ou incorrecte.Mais il est plus courant d’utiliser des noms dans le sens de

[DataContract]
Request{...}

et

[DataContract]
Response{...}

La demande et la réponse devraient idéalement être découplées de la représentation du modèle que vous utilisez dans le client et le serveur - c'est-à-dire que vous avez une façade ou un adaptateur qui les mappe à votre modèle à partir de votre code de service.

c'est dans le sens de la manière dont je le ferais - mais c'est très subjectif en fonction de la taille des entités, etc.

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top