WCF Part 2 : Defining contract

As seen in the previous article, we need an address, binding and contract to complete the WCF ABC. We’ll start at the contract.

A contract is defined explicitly, via a class. You add a [ServiceContract] attribute to the class. All methods you want to expose in your service, you mark as [OperationContract], as methods are called operations in services.

[ServiceContract]

public class Hello

{

    [OperationContract]

    string HelloWorld()

    {

        return “Hello world”;

    }

 

    string HelloComputer()

    {

        return “Hello computer”;

    }

}

The operations are defined explicitly, a Service Orientation tenet. HelloComputer won’t be visible by consumers of our service; it isn’t marked with an attribute. The HelloWorld operation however is, even though it’s private inside the .NET World.

Interfaces
We prefer however, to have an interface for our contract and have our actual service implement the interface. That’s because

  • Interfaces can extend/inherit other interfaces
  • A single class can implement multiple interfaces
  • You can modify the implementation of a service without breaking the contract
  • You can version your service via old and new interfaces

It’s always best to have an interface and implement it. The attributes also must be specified in the interface.

[ServiceContract]

public interface IHello

{

    [OperationContract]

    string HelloWorld();

 

    string HelloComputer();

}

 

public class Hello : IHello

{

    string IHello.HelloWorld()

    {

        return “Hello world”;

    }

 

    string IHello.HelloComputer()

    {

        return “Hello computer”;

    }

}

In the next article I’ll show you how you can host this service. In the future we’ll also consume the service and I will try to tell more about contracts and versioning.

[Go to the WCF series article index]

You may also like...

5 Responses

  1. posted says:

    [ServiceContract]

    public interface IHello

    {

    [OperationContract]

    string HelloWorld();

    string HelloComputer();

    }

    public class Hello : IHello

    {

    string IHello.HelloWorld()

    {

    return “Hello world”;

    }

    string IHello.HelloComputer()

    {

    return “Hello computer”;

    }

    }

  2. Parag says:

    As per author in Interfaces
    We prefer however, to have an interface for our contract and have our actual service implement the interface. That’s because

    * Interfaces can extend/inherit other interfaces

    This is wrong. Interfaces can not inherit other interfaces. Correct me if my assumption is wrong.

  3. Dennis van der Stelt says:

    @Parag : They can, they can even inherit multiple interfaces.

    public interface ISubInterface : IProduct, IRepository, IWhatever, ISomeThingElse
    {

    }

    And from there you can create a single class that must implement all those interfaces.

  4. Sree says:

    Hi,
    I have sample WCF application with interface as contract as shown in the above article but when i am trying to host the contract i am getting the following error

    The contract type MyFirstConsoleApplication.Mul is not attributed with ServiceContractAttribute. In order to define a valid contract, the specified type (either contract interface or service class) must be attributed with ServiceContractAttribute.

    Any help greatly appreciated.

    Thanks.

  5. Dennis van der Stelt says:

    Hi Sree,

    Some suggestions:
    1. Does your class (your implementation) implement the interface? ie. public class Mul : IMul
    2. Is the word “ServiceContract” in green? I hope so, else it wouldn’t compile! 🙂 But when you hover over it, is it from System.ServiceModel or another namespace?
    3. can’t think of anything else this early! 🙂

Click on a tab to select how you'd like to leave your comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.