I've developed a WCF Service that accepts Requests and processes based on a Request Type. However, I've ran into I think more of a design problem than anything. Most requests and responses are very quick and simple, small amounts of data being sent and received so this is great for the standard Buffered Transport Mode. However, there are a select few request types that can potentially return (from service to client) large amounts of data in which case I either have to set my MaxRecievedMessageSize very high or switch to a Streamed Transport Mode.
I've convinced myself that setting side the individual requests and creating a new Contract/Bindings/etc for the Streamed requests is the right direction. Now howevever I'm facing the challenge that I like to pass a Request Object (holds content about the request, its type etc) and this is a Data Contract. However, if I am going to convert to a Streamed Transport Mode I have the restriction of passing a Message Contract.
Can I extend a Data Contract and call the extended class a Message Contract and that work? For example:
[DataContract]
public class RequestObject
[MessageContract]
ExtendedRequestObject : RequestObject
If I can't go this route, what is the best way to make sure that the architecture still makes sense? I liked having to always pass one object in and being able to do validation on that object instead of having tons of methods/functions with multiple parameters etc?
I couldn't find a source but it seems odd and impossible. How would the DataMembers of the base-class be treated?
And inheritance seems unnecessary, how about aggregation:
[MessageContract]
class ExtendedRequestObject
{
[MessageBodyMember] RequestObject Request;
}