views:

229

answers:

3

If I don't keep Service Contract, proxy and Service in separate assembly, Service contracts and Proxies resides in Client assembly, And service resides in Service assembly.

If I do not keep data contract in a separate assembly, where should it reside, Client side or Service side?

Can Data Contracts reside in both assemblies?

A: 

I would strongly recommend having a separate assembly containing your interfaces and contracts that both client side and server side reference.

Joe
A: 

The answer is - it depends.

It is usually preferred to keep them separate, but there may be situations where keeping them together is just as good option.

When you keep them separate you can reference and use your data contract without dragging your operation contract with it, which gives you more flexibility in how you structure your application.

You can also version your contracts independently.

But it all depends on your actual application.

Krzysztof Koźmic
+2  A: 

In a typical, service-oriented scenario, you have the DataContract in your server-side service library. Anyone who will be calling you will be adding a client proxy connection to your service, and thus will be in fact duplicating your DataContract.

So in the "normal" case, you have your "master" DataContract on the server side, and a separate class in each of the client proxies accessing your service. Those client copies are "identical on the wire", e.g. they serialize into the same message format - which is really all there is between your client and your server - a serialized message being sent back and forth.

As a service developer, you definitely have to have your DataContract on the server side. But the same really also applies to the service contracts - those also have to be on the server side - otherwise you won't be able to publish your service interface to the world to be used by anyone who might connect to your service.

I would suggest the following at least two projects for each server:

  • a class library which contains the service contracts (IService interfaces), the data contracts, and possibly the fault contracts
  • a class library or self-hosted EXE (console app) that contains the actual service implementation (the classes implementating the service interfaces)

Marc

marc_s