Wcf Service Proxy Name / Namespace naming strategy

Question

Anyone have a naming strategy that works well for service proxy classes?

For example, if I am given three web services within two projects as follows:

XWs
  AService.asmx
YWs
  BService.svc
  CService.svc

What would use as the Service Reference Name & Namespace for AService, BService and CService ?

In general, I'd like something in the proxy name/namespace to indicate that the thing being used is not a concrete class, but represents a proxy - both so it doesnt clash with usage of concrete classes [and force usage of aliasing or namespace-qualified class names], and so we're not hiding the fact that there's a hop happening (I guess the Wcf Service Proxy generator's default suffix of Client covers that). Also important is that it deals with cases where one is writing a wrapper/shim service that is forwarding a [sub]set of calls to another referenced service.

I've used various styles (Adding Ws, ServiceProxy, Ref or Proxy suffixes? Prefixing with ServiceName.), but have never been fully happy with them.

What's worked well for you? Any style guides make reference to a naming style?

Edit: While Cheeso's answer covers the bulk of my question, I'm still interested in hearing answers on:

1. A strategy for namespacing proxy classes as in the example above
2. A style guide that mentions a naming strategy for proxies

Answer 1

I originally used names like ServiceNameProxy and ServiceNameSvcProxy. But, like you, I haven't been particularly satisfied with those names, and as a result I did not stick with them. Now I just resort to ServiceNameService or ServiceNameSvc.

Is the key thing you want to communicate to users of the class that the class is a proxy? The distinction you are making - between a proxy class and a concrete class - seems like applies and alligators. The opposite of concrete is abstract, no? And the proxy class generated by svcutil.exe is, in fact, concrete.

With a naming convention, I think you are trying to indicate that the proxy class communicates to a remote service. (When we call it a "proxy", we mean to indicate it stands in front of something, in this case the remote service. ) If that is the case, then why not ServiceNameService or ServiceNameConnection, or along similar lines? Like System.Data.OleDb.OleDbConnection or System.Data.SqlClient.SqlConnection.

My own chosen naming convention is in line with that. It indicates that the class represents a service, which is assumed to be remote. I don't care so much to accentuate the fact that it is a proxy-to-a-service. For practical purposes the fact that it is a Service is the key thing.

Answer 2

I am also exploring options here. I just read this article by Miguel Castro and he recommends separating out the service, service host, data contract and service contract and I am primarily trying to decide if I should keep all of my service contracts in a separate contract namespace or let those live in each service namespace. Reason for separating them out into their own namespace is that if other services utilized them they are in a more neutral location.

So for example this:

companyname.services.contracts.service1contract
companyname.services.service1

or this:

companyname.services.service1
companyname.services.service1contract