views:

46

answers:

3

Hi All,

I am new to Web/WCF/Services - so bear with me :)

I am trying to analyse the code-flow in a .NET application but I have a hard time understanding the reasoning behind using the following approach when it comes to exposing services :

Now, in the application, I have a C# Class Lib Proj which has a C# Class Library project called "XXX.YYY.Services " within which I have 2 files :

ISomeServiceProviderClass.cs SomeServiceProviderClass.cs

Within the ISomeServiceProviderClass.cs I have the following structure for code :

 [ServiceContract]
    public interface ISomeServiceProviderClass
    {
        [OperationContract]
        int SomeFunc();
    }

Then there is the SomeServiceProviderClass.cs class which is defined like so :

public class SomeServiceProviderClass: ISomeServiceProviderClass
{
    public int  SomeFunc()
    {

        /// some code to do the implementation..
    } 
}

This is a sample service structure in my Provider Application. Obviously the Consumer application is using this service to show results in its UI layer.

Now I want to know, what is the need to have the interface called ISomeFile.cs and then SomeFile.cs which implementes this interface ?

I guessed that one of the reasons could be to allow for different types of implementations in each of the class that implements this interface ... If that is the case, then why not have just a SomeServiceClass.cs file within which I have Virtual functions that can be overridden in derived classes ? Or why not have an Abstract class with abstract functions ?

A: 

The clue is in the [ServiceContract] and [OperationContract] attributes in the ISomeServiceProviderClass. These indicate that ISomeSomeServiceProviderClass is defining a WCF Service Contract.

This contract (ie, the interface) can be implemented by code on the server side to carry out the actual operations, and on the client side it is dynamically implemented by WCF to create a proxy that relays calls across the network to the server.

You would not want to use an abstract class in this case, because that would restrict the freedom of implementation for the server and client side objects.

Samuel Jack
Oh. Ok ...so on the client side, a proxy class is created ..this proxy class will have all the functions with the "[OperationContract]" attribute on them , right ? What about the implementation of these functions/methods in the proxy class - does the proxy class contain just the definitions like in the interface or does it also contain some implementation as in the SomeServiceProviderClass.cs ?BTW, thanks for the reply :)
Sandeep
It contains some implementation, but nothing like that in SomeServiceProviderClass. As I said, WCF dynamically generates code that takes the parameters you give when calling methods on the interfaces and passes them over the the network to the server.
Samuel Jack
Ok. I think I got it figured out a bit better now . thanks all !
Sandeep
A: 

In the service, ISomeServiceProviderClass is implemented by your SomeServiceProviderClass source code. However, on the client, ISomeServiceProviderClass is implemented by a WCF channel class that handles communication with the service.

Going via an explicit interface is not the only way in which this type of transparent communication could be achieved, but it's by far the simplest and cleanest method.

Christian Hayter
A: 

The pattern is called "contract first" and is used to explicitly separate the code contract (what you can hold to be true) from the implementation. Web Services are based on WSDL Contracts which are basically an XML representation of that contract.

Doobi