What to do when property name matches class name

Question

In our C# code, we have a class called Project. Our base BusinessObject class (that all business objects inherit from) defines a property:

public Project Project { get; set; }

This is normally not a problem as long as we stay within the C# codebase. However, these business object classes are exposed in web services over the wire. Some consuming languages (such as Flex's actionscript) cannot handle having a property with the same name as its class.

This naming conflict happens all over the place in our code. Sometimes it's easy to change the name of the property or class. Sometimes it's really hard. We've wracked our brains and can't come up with a good standard way to handle this. It's possible to rename the Project class to ProjectType or ProjectInfo, but this is ugly and breaks all of our consumers' existing code. We could leave the type name the same and change the name of the property to ProjectInfo, but this causes the same problem.

Does anyone have any guidance or best practices for such a situation?

EDIT: Responding to some of the suggestions given:

• Methods aren't exposed over the wire, so we can't use methods.
• I'd prefer a standard naming convention that also adheres to Microsoft's own naming standards.
• Exposing a different contract for Flex may be an option. However, we're using Weborb for Flex interop. Weborb uses reflection to match the property names exactly, rather than using XML or SOAP serialization. If anyone knows more about custom serialization with Weborb, that would be helpful.

Answer 1

I use camelCase instead of UpperCase, for the name of members (methods and properties).

This is against the standard naming conventions, however, so I can't call it a "best practice" (but, it's what I like).

So, in your example I'd be defining:

Project project { get; set; }

Answer 2

How about good old methods? (GetProject/SetProject OR the way .net does it - Thread.CurrentThread)

Answer 3

It sounds like you've got an intractable problem if you've already got the web service out there with the problematic name. If you can't change anything without breaking existing customers, and you can't leave it as it is without breaking Flex, someone's going to be broken.

You could potentially expose a parallel API at a different URL. I'd agree with shahkalpesh's suggestion of Get/Set methods where the properties would be problematic. The good thing about this is that you can make the decision once and then be consistent rather than needing to think about it each time. It also means you can probably automate the creation of the second API based on the first.

Answer 4

WTF has the name of a variable in one language got to do with a web service?

Someone has to be really lazy in their XML binding for implementation details to be exposed on the wire.

The whole point of WSDL/SOA is that you have a spec for a message which is independent of implementation. If you generate message specifications from source code, or generate source from the specifications without allowing for variation of the generated objects, you end up with tightly coupled systems. One symptom of this tight coupling is getting variable/property names that aren't legal identifiers. A service (rather than an RPC) is not tightly coupled. You should not have to vary your service implementation to cater for the implementation of the service - if you have to, something in your stack is broken. That goes for member variables/properties as well as methods.

Answer 5

Although it's not really of help for external languages it is possible to alias namespaces (presumming the class Project is in a difference namespace to the class with the property Project), like so:

using ns = MyProject.Namespace;

Then you just have to do:

var newProject = new ns.Project();

Answer 6

I think the best solution is refactor your project to rename the object Project to something else WnProject, ProjectBase, or something else relevant to what exactly project is.

It's your API, anyone consuming it has to understand it's possible to have breaking changes shipped it's the cost of being dependent on external sources.