Overloading Methods in WCF

21. September 2006 04:33

Yesterday, I attended a local MSDN event in the Birmingham area.  It covered the .NET 2.0 System.Net namespace, an introduction to WCF, and a look at Atlas.  During the course of the WCF overview, someone asked the presenter whether it was possible to overload a method in WCF.  The presenter wasn't completely sure and there were mixed answers from people in the audience.  So, I thought I would provide the correct answer.

The short answer is yes.  Technically, it is possible to overload a method in WCF.  However, when you want to expose overloaded methods as operations in a WCF contract, there is more to it than simply writing two or more methods with the same name.

Consider the following example:

[ServiceContract]
public interface ICalendarService
{
   [OperationContract]
   ScheduledEvent[] GetScheduledEvents(DateTime date);

   [OperationContract]
   ScheduledEvent[] GetScheduledEvents(DateTime start, DateTime end);
}

Now, try to actually implement this interface and host it as a WCF service.  Kaboom!  An InvalidOperationException will be raised when you invoke ServiceHost.Open.  Jeff, I thought you said that methods could be overloaded in WCF.  What gives?

As far as the C# compiler is concerned, this is a completely legal piece of code.  The interface contains two methods.  The methods have the same name, but their signatures are unique since their parameters differ.  The interface and methods are decorated with attributes.  However, WCF doesn't have any special hooks into the compiler.  Consequently, the compiler doesn't have any special knowledge about the attributes.  It is simply going to emit their information in the assembly metadata.

When WCF attempts to start the service, it essentially interrogates the metadata to generate a WSDL contract.  WSDL is all about technology neutral, message based communication.  It doesn't support object-oriented concepts such as inheritance and overloading.  (Actually, I think the earliest versions of WSDL allowed overloading to a certain extent, but it has since been removed in the newer versions.)  So, WCF basically detects there are two methods with the same name and raises an exception to indicate this isn't allowed even though the code compiled without any errors. 

Regardless, WCF still provides the ability to overload methods.  This can be achieved by using the name property of the OperationContract attribute.  By default, the name of the method will be used for the value of the name property.  However, you can explicitly set the value of the name property to provide a unique value.  Under the covers, WCF will use the value you supply as the name of the corresponding operation in the generated WSDL. 

Here is our previous example revised to use alias method names:

[ServiceContract]
public interface ICalendarService
{
   [OperationContract(Name = "GetScheduledEventsByDate")]
   ScheduledEvent[] GetScheduledEvents(DateTime date);

   [OperationContract(Name = "GetScheduledEventsByDateRange")]
   ScheduledEvent[] GetScheduledEvents(DateTime start, DateTime end);
}

You may be wondering how the method will appear to the consumer of the service.  Will it appear as two different names (based on the the alias) or as overloaded methods with the same name?  This will depend upon the proxy class used by your client.  If you use the proxy class that is automatically generated by svcutility.exe, the alias method names will be used.  However, you can manually edit the generated proxy class to achieve the appearance of overloaded methods on the client as well.  This can be accomplished by applying the same attributes to the methods defined in the interface that is used by the proxy class.

As you can see, overloading of methods is possible in WCF.  However, there is another question that remains to be answered.  Just because you have the ability to overload methods exposed in the contract, should you do it?  There are a lot of varied opinions about this type of question.  It is hard to say whether any of them are definitively right or wrong.  Personally, I am in the camp that you should avoid it unless there is a compelling reason. 

Don't get me wrong.  There is absolutely nothing wrong with method overloading in the realm of object oriented programming.  However, object oriented development doesn't translate directly to service oriented development.  I don't think it is generally a good idea to expose overloaded methods as part of a service contract.  It is a specific object-oriented concept that doesn't really fit into the semantics of service orientation.

At any rate, to answer the question of the person at the MSDN event...yes, it is possible to overload methods exposed as operation contracts in WCF.

Comments

1/12/2010 5:33:38 PM #

trackback

WCF Method overloading

WCF Method overloading

Roodev.com |

8/31/2011 9:51:54 AM #

pingback

Pingback from programmersgoodies.com

Methods with the same name in different endpoints - Programmers Goodies

programmersgoodies.com |

3/16/2012 12:09:21 PM #

pingback

Pingback from dev.zemna.net

Overloading Methods in WCF | Dev.Zemna.Net

dev.zemna.net |

10/24/2012 11:27:19 PM #

pingback

Pingback from dotnethorizon.wordpress.com

Want to overload your methods in WCF? Watch out! « .Net Horizon

dotnethorizon.wordpress.com |

6/11/2013 7:10:09 AM #

trackback

Overloading Methods in WCF

Overloading Methods in WCF

Bryan Avery - Blog |

Comments are closed

About Me

I'm a passionate software developer and advocate of the Microsoft .NET platform.  In my opinion, software development is a craft that necessitates a conscious effort to continually improve your skills rather than falling into the trap of complacency.  I was also awarded as a Microsoft MVP in Connected Systems in 2008, 2009, and 2010.


Can’t code withoutThe best C# & VB.NET refactoring plugin for Visual Studio
Follow jeff_barnes on Twitter

View Jeff Barnes's profile on LinkedIn

 

Shared Items

Disclaimer

Anything you read or see on this site is solely based on my own thoughts.  The material on this site does not necessarily reflect the views of my employer or anyone else.  In other words, I don't speak for anyone other than myself.  So, don't assume I am the official spokesperson for anyone.