views:

719

answers:

2

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
+1  A: 

I originally used names like ServiceName**Proxy** and ServiceName**SvcProxy**. 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 ServiceName**Service** or ServiceName**Svc**.

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 ServiceName**Service** or ServiceName**Connection**, 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.

Cheeso
Hi Cheeso, Thanks for taking the time to reply. I got distracted immediately after posting the question hence the mad wait... I guess the svcutil `Client` suffix isnt the end of the world for the name of the proxy class. The question of what namespace to put stuff in (esp if you're using two endpoints on the same app (YWs above) remains unanswered though. Still also interested in seeing it referred to in a style guide too... Anyway, thanks!
Ruben Bartelink
+1  A: 

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
Tone
I wouldn't go down the 'companyname.services.contracts' route - remember any proper service should be completely autonomous. Having a central 'contracts' space is like having a utils project - everybody piles in and you end up with 40% being decent quality and 60% being used and no way to untangle it. Even having a 'Services' base in your tree is questionable for me.
Ruben Bartelink
To go even further - the companyname bit is debatable - what if you merge? Do you want people to have to rename? What if you rebadge? What if you acquire another company or it yours - is it critical that half your services post-merger are in a different naming tree? Just saying really; You do want something where you have 'companyname.services' to give you a fighting chance of `service1` never clashing with other assemblies that you touch. Remember though that the real namespace is the WSDL namespace *within* your Contract.
Ruben Bartelink
My question was definitely on the client side of things, and that's what I see Miguel's article touching on from a quick scan. So, to summarise, I'd pick a `FamilyRootIfService1IsPartOfAFamilyOfServicesButNotJustACompanyNameIfItCanBeAvoided.Service1.Contracts`. If you're going to put your contracts for each service in a namespace and project, I'd go with `Root.Service1.Contracts` (rather than Service1Contracts to to make the relationship between `Service1.Contracts` and `Service1` clear. And call your assembly, .csproj and project directory the very same as the namespace: `R.S1.Contracts`
Ruben Bartelink
Hope the above gives some food for thought. I be there's a better more in depth general namespace discussion out there though. I'm very happy with my current thinking on it, but have been around the houses and sunk plenty time into this 'silly' discussion many times!
Ruben Bartelink
This is good feedback. Thanks for the thoughts Ruben. I agree it seems like a silly discussion, but actually ends up being more important than it first lets on.
Tone