Sharing types between WCF services and their .net clients

Sharing types between WCF services and their .net clients

While I know that this can be done, I somehow feel there is something fundamentally wrong in the design when you feel the need to use an assembly on the service and use the same on the .net client.

I needed to do this because I have a data contract that will be used in two different services. When both those services are referenced on the same client they will result in the same data type being available in two different namespaces. That to me looked like it will create problem of ambiguity when being used by the client, or at the very least look redundant. Plus, if I am sharing types like this doesnt it defeat the purpose of having a service?

What are your thoughts on sharing types betw开发者_如何学Goeen the service and the client like this? Does it sound like bad design that will lead to some other unforeseen problems later on? ...or just unusual design in general!

Service/DataContract are exactly what the word says: Contracts. The whole point is to share it - nothing wrong with this, and you should consider the types as part of the same Contract (you can just share interfaces to your types if you prefer).

Obviously you can always go the wsdl way and share that as your contract plus a bunch of xsds defining your types, but in the end you're doing the exact same thing, just going one step further and if you know both your client and service are gonna be .NET you don't really need to.

It depends on the intent. If the purpose if your service is to have a logical and/or physical boundary between layers, then usig the same type on either side of the boundary does nothing to harm that, and can make everything work a lot more conveniently. It also gives you a single type model to test etc.

The mex/wsdl approach is especially useful when exposing a public service interface, or where cross-platform portability is an issue. But if you don't need that, it can be very tempting (right or wrong) to re-use the types. An overly simplified version of this can even be when an app talks to the same app on a different node via some private API - introducing a separate type model here adds little. Additionally, sharing the types can give a more typical (less code-gen foolery) API, and with the logic in the types to perform validation you can get richer validation.

I would approach this more from a "what do I need/expect" from this service; if "it must be cross-platform and independent of the type-model in my core application" isn't on the list, maybe cross that bridge if/when it arises.

I only do this to share validations and constructor logic. Everything else belongs in either server or the client so I do not want to share that.

This depends on the usage scenario. If you don't share the assembly containing the contracts you are pretty much forcing the client to create a service proxy by using a service reference - and all the generated code that entails. If you share the contracts you will have more control of your client side code. You will also eliminate the need to regenerate service references any time your middle-tier services interfaces change.