views:

172

answers:

1

Hi -

We currently have several WCF services that expose our domain model directly across the wire. In other words, we don't have a layer of DTOs to map between our domain and service layers. I have no choice but to directly decorate our domain objects with [DataContract] and [DataMember]. I want to implement IExtensibleDataObject on all of our domain objects that are exposed on the wire. Does anyone sees anything wrong with implementing IExtensibleDataObject on a base class? So I would have:

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

[DataContract] 
public Person:EntityBase{}

[DataContract]
public Employee:Person{}

Thanks in advance

A: 

Thanks Matt. I guess I know that it works fine, but my questions is more related to SOA design. I know in the OO world this is just fine, but since my domain objects are also serving as DTOs I'm worried that adding this inheritance chain will lead to issues down the road. Is anyone else implementing IExtensibleDataObject? If so, are you implementing the IExtensibleDataObject on all your datacontracts or on a base class?

My apologies as I misunderstood what you were asking. From a pure SOA perspective, it is not desirable to have a mechanism like IExtensibleDataObject as it can mask things from a contract perspective. That being said, I think the idea was one of convenience. Here's a good post that contains both the pros (the post itself) and the cons (the first comment): http://bloggingabout.net/blogs/vagif/archive/2009/03/29/iextensibledataobject-is-not-only-for-backward-compatibility.aspx
MattK