I apologize if this is a little vague, but I'm curious about what most people use for naming conventions for classes that access a webservice. Typically on my team we create separate projects for BLL (business rules), Model (DTOs and ASP.NET model classes), and Data ( typically Db and WS I/O ).

My question is in regards to what teams do for classes that access services. Typically in our Data project we postpend 'Dao' to the class name that queries the objects in the Db. So for example a class that does CRUD operations in a Db on Foo objects we typically name FooDao.cs and there seems to be general consensus on the team for that pattern. But what do teams do for classes that query webservices? Sometimes we name them as FooFacade.cs, or FooSvcClient, or even FooSvc.

I understand there probably isn't a true right or wrong answer here, but I want to know what others do, and if there is momentum towards a particular approach.

  • Why the downvote? Are best practices type of questions not desired in this forum? Commented Feb 16, 2017 at 16:31
  • can you add an example of all the classes you make for a single 'object type'?
    – Ewan
    Commented Feb 16, 2017 at 16:46
  • Is this a JSON webservice or an XML webservice? Does it have a WSDL? Commented Feb 16, 2017 at 17:08
  • @RobertHarvey We consume both SOAP and restful services. Commented Feb 16, 2017 at 18:23
  • 1
    I do not know about common practice but since you are keen on using 3-letter suffixes that convey the stereotype you could apply Wsc to your web service consumers. Commented Feb 16, 2017 at 19:15

3 Answers 3


Code that accesses a service is generally called a "Client."

Since class names should be descriptive, the name of your class should probably include the word "client," since that's what the class is. You can make that moniker as descriptive as you like: JsonWebServiceClient, for example.

In addition, I think it would be useful if the class name also included the name of the type being retrieved, or a description of the operation being performed. So, for example, if you were retrieving a Customer object from a json web service, your class name might be


or even


To add some weight to these assertions, here is an example from ServiceStack.Client, a library that allows you to write generic clients against XML and JSON web services:

enter image description here

Notice how the name of the client class is XmlServiceClient, and the Post method accepts the expected return type as a parameter.

Whatever you do decide, make sure that the naming convention you settle upon is agreed upon by the team and then strictly followed. The cost of whatever convention you do adopt is 2 minutes with each new developer explaining how it works, or documentation to that effect.

  • Thanks we've used client as well. A downside to that is that when you start to consume WCF services through 'Add Service Reference' the tool generates proxy classes with 'client' in the class name and it might start to get confusing as to where my code stops and the generated code starts ( although namespaces could resolve that issue) Commented Feb 16, 2017 at 22:43
  • If the tool is properly designed, it is writing comments into the classes to that effect: "Generated Code - Do Not Modify." Those classes are also typically partial classes, allowing customization code to be written without it getting overwritten by the code generator. Commented Feb 16, 2017 at 23:15

Two terms I see frequently are "client" and "proxy."

To me, a proxy is just a very simple (sometimes autogenerated) DLL that adheres to a WSDL or other contract. Members of the proxy map one-to-one to members of the service itself, so there is no abstraction. It allows the caller to access the service without worrying about creating an HttpClient or WebClient or anything transport-related.

A client on the other hand is more likely to contain a bit more value-added logic to make the service easier to use. For example, it may take care of the details of authentication and session management, or may wrap several different services that need to be coordinated. But this is not always the case, sometimes it is just a proxy.

  • Thanks, we haven't used proxy before but I think we need to consider it. I think we've used 'facade' before but in reality 'proxy' might be more appropriate because we like to create small classes that invoke services to isolate the service IO responsibility. So the classes do nothing more then invoke the service, maybe map to the result to a DTO and return. Commented Feb 16, 2017 at 22:47

I tend to use Gateway. This conforms with the Gateway pattern as described by Martin Fowler https://martinfowler.com/eaaCatalog/gateway.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.