Well, I think this is another case of the SOA vs. OOP "impedance mismatch". The two world are quite separate.
In WCF, all that is being passed from the client to the server is passed as serialized messages - no references are being used.
This means: everything you want to serialize on the client, send it across to the server, and deserialize it and use it there, must be concrete - you cannot pass around interfaces, you cannot use "non-resolved" generics - you need to spell it out. Basically, all that's being passed from client over the wire to the server must be expressable in XML schema.
This has lots of implications:
- no interfaces - you cannot pass around interfaces - you need to work with concrete types
- no "automatic" inheritance - you cannot just define a base class and pass around derived classes based on it - those need to be specificied too (that's what the ServiceKnownType attribute is for)
- no automatic generics - again, you need to use concrete types instead
This may sound like a lot of restrictions - but it's because WCF is using all message-based communication - it cannot deal with refereces, inheritance, generics etc. - you need to spell it out.
So I don't really have an answer for you per se - I just think you need to rethink your strategy and change the way your client and server are exchanging information over WCF.
Marc
PS: I did some more research, and contrary to all my understanding, there seems to be a way to serialize anything that's based on an interface and/or abstract base class across the wire, as long as you can be sure it's always only .NET on either end of the wire (i.e. it's not interoperable with e.g. Java).
See Aaron Skonnard blog post on the NetDataContractSerializer and another blog post and yet another showing how to use the NetDataContractSerializer to be able to pass around things like IPerson
as parameters to your methods.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…