Service - client interface, architecture advice

I have a Windows WCF serivce and Web client. My service has one method

[OperationContract]
SubmitOrder(OrderInfo info)开发者_开发百科....

// class used to pass all relevant data
[DataContract]
class OrderInfo
{
 [DataMember]
 OrderType Type;
 // general order data
}

It was great until I have introduced new order types (controlled by OrderInfo.Type property). You can think of new order type as derived from general order (in terms of behaviour). Each new order has some additional properties. What is the best approach to implement this polymorphic behaviour of Order?

Currently I simply add new properties to OrderInfo class while adding new orders.

[DataContract]
class OrderInfo
{
 [DataMember]
 OrderType Type;
 // general order data

 // First custom order data
 // Second custom order data
 // TODO - add new properties for new orders
}

I don't like it much cause it too straight. What if I change [DataContract] and the client is not rebuilt?

What are my alternatives? I can of course implement inheritance and derive new [DataContract] class like MyCustomOrder1, but inheritance is not supported by serialization, I need to use [KnownTypes] which is forbidden due to some reasons.

Off the top of my head and I'm not sure this is a great idea, but I think a way to do this would be to relax your contracts on the service side, e.g. use a MessageContract instead and accept 'any' content in the message. You can still distribute your datacontracts to your clients, so you have the benefit of programming your client against a model. On the service side, you then need to figure out what kind of content the message contains and act accordingly.

I'm not sure about the details of how to implement this, but I'd start by looking at the Message class in WCF: http://msdn.microsoft.com/en-us/library/ms734675.aspx

It boils down to using 'untyped' messages as explained here: http://geekswithblogs.net/claeyskurt/archive/2008/09/24/125430.aspx as previously discussed here: WCF and Anonymous Types

A completely different way (and maybe cleaner?) to do this would be to use IExtensibleDataObject as explained in part 2 of this post http://geekswithblogs.net/claeyskurt/archive/2008/05/02/121848.aspx.

edit: I was reading about data contract versioning and I thought of what could be a better solution

If for whatever reason you can't use KnownType, what you're doing boils down to creating new versions of your contract. The easiest way to start would be to

• create a single orderinfo contract with all the properties of the subtypes
• add a 'type' property (a string, because you can't just add new enumerations afterwards, this would be a breaking change)
• make all the properties that were on the base class 'required'
• make all the properties that were on the subtypes 'optional'
• implement IExtensibleDataObject to be forward-compatible
• in our service, use the type property to determine what kind of order it is and act accordingly

Now, when you're adding new types, add the new properties to the OrderInfo class, and as long as they are optional and the rest of the class doesn't change, you'll be backwards compatible with your clients who don't have the new version of your contract yet. Yes, it could get messy on the client side, but you can always abstract this away behind some helper classes.

I need to use [KnownType] which is forbidden due to some reasons.

What do you mean by forbidden? I don't have any issue using the KnownTypeAttribute. Here's an example.

[DataContract]
[KnownType( typeof( NetworkDeviceProperties ) )]
public class DeviceProperties
{
    [DataMember]
    public string MachineName { get; set; }
}

[DataContract]
public class NetworkDeviceProperties : DeviceProperties
{
    [DataMember]
    public IPAddress IPAddress { get; set; }
}

[ServiceContract]
public interface ICollectionService
{
    [OperationContract]
    [ServiceKnownType( typeof( NetworkDeviceProperties ) )]
    void Start( DeviceProperties properties );
}

On my client side, I create a NetworkDeviceProperties object and pass it without issue to the Start() method. Refer to this blog for additional information.