Should the Service Contract(Interface) be exposed to the Client?

In the process of learning WCF.

To examplify, lets say I have 3 assemblies :

1.) Service.Contract : It has the definition of the interface MyType IMyInterface();

2.) Service : It has the implementation of the interface MyType MyService() : IMyInterface;

3.) Client : It calls the service.

My basic question is should 'Service.Contract' project be exposed to the 'Client' project as it needs to know the prototype of the interface. If yes, i开发者_Python百科s it not against the SOA principles ? If no, then how do we achieve a call to the Service with just the endpoint address ?

Yes. The interface needs to be exposed to the client. Otherwise the client does not know what methods are available on the service.

There are tools available that can be used to generate the interface code for you from your service's metadata (assuming you are exposing the service data), so the client does not need the actual interface file. This is essentially what is happening when you use Visual Studio (or another dev tool) and use "Add Service Reference".

Alternatively there is a command line tool that ships with dotNet - SvcUtil.exe:
http://msdn.microsoft.com/en-us/library/ms733133.aspx
http://en.csharp-online.net/WCF_Essentials%E2%80%94Generating_the_Proxy

I don't see how this would breach SOA principles. As my previous comment said. How would the client know how to call your service if it doesn't know what the implemented contract is?

The general method is you add a service reference to your project which create client based classes which implement the published data contracts and client calling functions to your service. You don't in actuality use the interfaces which define the services or the classes which define your data contracts.