2010-01-11 2 views
1

Nous avons actuellement plusieurs services WCF qui exposent directement notre modèle de domaine sur le réseau. En d'autres termes, nous n'avons pas de couche de DTO à mapper entre nos couches de domaine et de service. Je n'ai pas d'autre choix que de décorer directement nos objets de domaine avec [DataContract] et [DataMember]. Je veux implémenter IExtensibleDataObject sur tous les objets de notre domaine qui sont exposés sur le réseau. Quelqu'un voit-il quelque chose de mal à implémenter IExtensibleDataObject sur une classe de base? Je devrais donc:Implémenter IExtensibleDataObject sur une classe de base

[DataContract] 
public EntityBase:IExtensibleDataObject{///IExtensibleDataObject Impl} 

[DataContract] 
public Person:EntityBase{} 

[DataContract] 
public Employee:Person{} 

Merci à l'avance

+1

Votre code devrait fonctionner correctement. En fait, si vous regardez le code généré par svcutil, vous verrez un code qui ressemble au vôtre. Consultez ce lien pour plus d'informations: http://msdn.microsoft.com/fr-fr/library/system.runtime.serialization.iextensibledataobject.aspx – Kwal

Répondre

1

Merci Matt. Je suppose que je sais que cela fonctionne bien, mais mes questions sont plus liées à la conception SOA. Je sais que dans le monde OO, c'est très bien, mais comme mes objets de domaine servent également de DTO, je crains que l'ajout de cette chaîne d'héritage ne conduise à des problèmes plus tard. Est-ce que quelqu'un d'autre implémente IExtensibleDataObject? Si oui, implémentez-vous IExtensibleDataObject sur tous vos contrats de données ou sur une classe de base?

+0

Mes excuses car j'ai mal compris ce que vous demandiez. Du point de vue purement SOA, il n'est pas souhaitable d'avoir un mécanisme comme IExtensibleDataObject, car il peut masquer les choses d'un point de vue contractuel. Cela étant dit, je pense que l'idée en était une de commodité. Voici un bon post qui contient à la fois les avantages (le message lui-même) et les inconvénients (le premier commentaire): http://bloggingabout.net/blogs/vagif/archive/2009/03/29/iextensibledataobject-is-not-only -pour-backward-compatibility.aspx – Kwal

Questions connexes