WCF and interface inheritance - Is this a terrible thing?

Question

My application has 2 "services", let's say that this is a basic (integer) calculator, and one is a floating point calculator. I express them as interfaces:

public interface IBasicCalculator { int Add( int a, int b ); } public interface IFloatingPointCalculator { double Add( double a, double b ); } 

I want to expose them through WCF. Unfortunately, WCF seems to be very closely connected with the notion that every possible operation that you want to open must go through one service interface - you cannot exchange sessions between services, this is cumbersome on the client side, since you need to create a separate proxy -server for each of them, it seems, there are no "sub-services", etc.

So, I realized that I need to introduce a “combined” interface (you can also call it a facade), for example:

 [ServiceContract] public interface ICalculatorService : IBasicCalculator, IFloatingPointCalculator { [OperationContract(Name = "AddInt")] new int Add( int a, int b ); [OperationContract(Name = "AddDouble")] new double Add( double a, double b ); } 

If I do this, WCF provides the client with both methods that can call them, and it all really works.

However, "interface inheritance" seems to be inconvenient. In particular, new int Add and new double Add . Strictly speaking, new by the method indicates hiding the base method, which I do not do at all. I can omit new , but then I just get compiler warnings that make up "I think I'm hiding this method, you need to rename it or put" new "on it.

So this is a two-part question:

• Am I in the know with my “combine all into one interface” logic, or is there a way to open “sub-services” or “several related services” using WCF?

• If this is what needs to be done, is there a better way?

Thanks!

Answer 1

I just decided that you can provide several endpoints (each of which uses a different interface) for the same service, and you still need to create only one proxy server on the client that gives access to all of them, which completely solves my problem.

Answer 2

I would say no at all. Remember that you are dealing with technology for distributed applications, not technology for distributed objects, so concepts such as inheritance do not apply.

In general, I would not go this way, but rather had specific contracts, which are a logical grouping of operations that you want to open through the endpoint.

Answer 3

I believe that what you are describing is not really the best practice. Undoubtedly, it is possible to implement more than one contract for a service such as Service, since this is just a matter of introducing several interfaces.

WCF certainly makes it possible to support multiple endpoints that communicate using unique URIs and independent contracts. However, the fact that the ClientBase class accepts only one type of contract interface, for example, largely implies that proxy classes, even if they are stored in the same library, still need to clearly implement only one contract interface.

If you really manage to create only one proxy class definition, I would like to know how you managed to do this. However, I may not understand your needs. Implementing different proxy classes gives you maximum flexibility, because OperationContractAtrribute values, such as IsInitiating and IsTerminating, can be different for different contracts. The combination of the interfaces of the two contracts, as in your example, potentially changes the way you should attribute the methods in the service contract.