다음을 통해 공유

Method Overloading in WCF

  • 아티클

WCF solves so many complex problems of the distributing computing, yet when it comes to simple things like overloading it fumbles. This is not what I say, but what I heard from some developers at my customer's site. So, I thought how can such a small thing could not be achievable in WCF when the underlying platform (.Net framework) support this by design.

After little thought, it is all clear why it does not work the same way it works with compiled languages. Its all the underlying protocols that makes it complex. But, it is not really tough to get this to work.

Here is the sample I worked on to get method overloading with WCF working like it does in C#.

Step 1: I've created a simple service contract with two methods using method overloading.

 [ServiceContract()]
public interface IMathService
{
    [OperationContract]
    int AddNumbers(int num1, int num2);
    [OperationContract]
    double AddNumbers(double num1, double num2);
}

Step 2: Tried to run the service and this is what I WCF told me...

image

Step 3: As WCF does not allow me to do this in a direct way, I looked at the OperationContract attribute to see if there is something that can help me. To my confidence, there is this property called Name. I've set this value to a unique value for both of these methods. now, the service contract looks like this:

 [ServiceContract()]
public interface IMathService
{
    [OperationContract(Name="AddIntegers")]
    int AddNumbers(int num1, int num2);
    [OperationContract(Name="AddDoubles")]
    double AddNumbers(double num1, double num2);
}

Step 4: Tried to run the service and this is what WCF told me now...

image

The problem seemed to be solved. And indeed it is, the generated proxy does not show any discrimination towards these methods. They'll be just like any other method (overloaded methods). Now its all over... Method overloading in WCF is very much possible and is very much simple.

I don't think I need to attach the source code as the only required change is already discussed here.

Note: If you are using WCF always think about messages and not methods. So, this situation should not end up in your design docs. If at all you end up here, you can use the approach suggested in this blog. Thanks Michael for pointing out this.

Comments

  • Anonymous
    August 31, 2007
    WCF solves so many complex problems of the distributing computing, yet when it comes to simple things

  • Anonymous
    September 01, 2007
    The comment has been removed

  • Anonymous
    September 01, 2007
    I completely agree with you that we are sending messages, but unfortunately SO is not completely into developers mindset. As long as OO dominates, these questions always end up from someone or the other.

  • Anonymous
    September 01, 2007
    I think this is a pretty poor justification for trying to say that it supports overloading. WCF simply doesn't support overloading - as far as I can tell it's 100% impossible and that's precisely why you have to use the OperationContract name attribute to work around the problem. That's not a flaw of WCF though at present, and you would have been better positioning the article as a defense of the fact that it can't support overloading because the standards it complies with (SOAP's WSDL in later versions) don't support it. What I don't understand is why someone made the decision to enforce this in the ServiceHost and not when adding the end point/metadata.  It was clearly a decision that should be made by the transport medium rather than the WCF service hosting layer. As it currently is even if a communications standard that does support overloading comes out WCF will not be able to support it. And whilst it's not flawed now, if that happens it will be.

  • Anonymous
    September 02, 2007
    Sure, but the right response isn't "you can tag it to get around it". The correct response is "redesign your interface properly". If you explain how to get "get around it", you should still disclaim that it's still not a great idea and they need to look at their design.

  • Anonymous
    September 02, 2007
    Hi Simon, I can understand what you mean. But imagine a developer consuming your WCF Service and does not know what WCF is and how it works. All they are interested is "if is it working or not". If you have two similar functionality, a non WCF developer expects an overload there. Irrespective of the underlying platform. And why do you think this decision should be made by the transport medium? Do you expect your service behave differently for different medium?

  • Anonymous
    September 02, 2007
    But what if you made a transport that COULD support overloaded methods?  Or maybe updated ALL the WCF transports so they supported it?  Currently you can't use the feature with WCF so it's flawed. If you were using WsHttpBinding and a hypothetical transport then it would still be correct for it to be an error condition, hence it should be a transport level decision as to whether to error. And before you say "nobody would ever implement overloaded methods in a webservice!", well WSDL 1.1 did indeed support it and it would seem like a fundamental feature to support at your abstraction layer to me.

  • Anonymous
    July 09, 2010
    Hello All, Below is the link that provide good explanation of possibility of Method overloading and trick to achieve  Method overloading in SVC aspdotnethacker.blogspot.com/.../wcf-service-method-overloading.html

  • Anonymous
    May 16, 2012
    I think this is more trouble than it's worth.  When you would next update the reference, the interface and the partial classes would get overwritten. You would have to remember to do this every time