Wcf namespace / namespace name naming strategy

Question

Does anyone have a naming strategy that works well for proxy classes?

For example, if I am provided with three web services in two projects:

XWs AService.asmx YWs BService.svc CService.svc 

What will be used as the service reference name and namespace for AService , BService and CService ?

In general, I would like to indicate something in the proxy name / namespace that the thing used is not a specific class, but is a proxy server, so it does not interfere with the use of specific classes [and forced use of aliasing or class names with names], and therefore we do not hide the fact that the flight is taking place (I believe that by default for the Wcf Service Proxy the suffix Client is used by default). It is also important that it deals with cases where you write a wrapper service / shim that redirects the [sub] set of calls to another reference service.

I used various styles (adding Ws , ServiceProxy , Ref or Proxy suffixes? Prefix using ServiceName. ), But they were never fully satisfied with them.

What worked for you? Do any style guides reference a naming style?

Edit: although the answer “Chiso” covers the bulk of my question, I'm still interested in hearing answers to:

• Strategy for proxy class names, as in the example above
• A style guide that mentions a proxy naming strategy.

Answer 1

I originally used names such as ServiceName Proxy and ServiceName SvcProxy . But, like you, I was not particularly pleased with these names, and as a result, I did not adhere to them. Now I just resort to ServiceName Service or ServiceName Svc .

Is the keyword that you want to tell class users that the class is a proxy? The distinction you make - between the proxy class and the concrete class - seems to apply to alligators as well. The opposite of the concrete abstract, no? And the proxy class created by svcutil.exe is actually specific.

With a naming convention, I think you are trying to indicate that the proxy class is communicating with the remote service. (When we call this a “proxy”, we want to indicate that it is facing something, in this case a remote service.) If so, then why not a ServiceName Service or ServiceName Connection or along similar lines? Like System.Data.OleDb.OleDbConnection or System.Data.SqlClient.SqlConnection.

The own chosen naming convention matches this. It indicates that the class is a service that is considered remote. I don’t care to emphasize the fact that this is a proxy service. For practical purposes, the key point is the fact that this is a Service.

Answer 2

I am also exploring options here. I just read this article by Miguel Castro, and he recommends separating the service, the host of the service, the data contract and the service contract, and I’m primarily trying to decide whether I should keep all my service contracts in a separate contract namespace or allow im living in every service namespace. The reason for dividing them into their own namespace is that if other services use them, they are in a more neutral place.

So for example:

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

or that:

 companyname.services.service1 companyname.services.service1contract