属性名称与类名匹配时要执行的操作
在我们的C＃代码中，我们有一个名为Project的类。 我们的基础BusinessObject类（所有业务对象都inheritance自）定义了一个属性：
public Project Project { get; set; } 只要我们保持在C＃代码库中，这通常不是问题。 但是，这些业务对象类通过网络在Web服务中公开。 某些消费语言（例如Flex的动作脚本）无法处理具有与其类同名的属性。
这个命名冲突发生在我们代码中的所有地方。 有时，更改属性或类的名称很容易。 有时它真的很难。 我们绞尽脑汁，无法想出一个很好的标准方法来处理这个问题。 可以将Project类重命名为ProjectType或ProjectInfo，但这很丑陋并且会破坏我们所有的消费者现有代码。 我们可以保留类型名称相同并将属性的名称更改为ProjectInfo，但这会导致同样的问题。
有没有人对这种情况有任何指导或最佳做法？
编辑：
回应一些建议：
- 方法不会通过电线暴露，因此我们不能使用方法。
- 我更喜欢标准的命名约定，它也符合微软自己的命名标准。
- 可以选择为Flex公开不同的合同。 但是，我们正在使用Weborb for Flex interop。 Weborb使用reflection来精确匹配属性名称，而不是使用XML或SOAP序列化。 如果有人了解有关Weborb的自定义序列化的更多信息，那将会很有帮助。
编辑＃2：
作为参考，我们最终将属性重命名为：
public Project ProjectInfo { get; set; }
听起来你有一个难以处理的问题，如果你已经有了有问题的名字的网络服务。 如果你不能在不破坏现有客户的情况下改变任何东西，并且你不能在不破坏Flex的情况下保留它，那么某人就会被打破。
您可能会在不同的URL上公开并行API。 我同意shahkalpesh关于Get / Set方法的建议，其中属性会有问题。 关于这一点的好处是你可以做出一次决定，然后保持一致，而不是每次都要考虑它。 这也意味着您可以基于第一个API自动创建第二个API。
我认为最好的解决方案是重构你的项目，将对象Project重命名为WnProject，ProjectBase或其他与项目确切相关的东西。
这是你的API，任何消费它的人必须明白它可能会发生重大变化，这是依赖外部资源的成本。
我使用camelCase而不是UpperCase作为成员名称（方法和属性）。
然而，这违反了标准的命名约定，所以我不能称之为“最佳实践”（但是，这就是我喜欢的）。
所以，在你的例子中，我将定义：
Project project { get; set; }
好老方法怎么样？ （GetProject / SetProject或.net的方式 – Thread.CurrentThread）
我知道这是一个老问题，但它可能对其他人有所帮助。
为什么不为不支持相同道具名称和类型的消费者提供不同的WSDL？
重命名WSDL中的complextype（不是元素名称！）
从你应该拥有的东西：
至：
在这种情况下，SOAP消息将保持完全相同，这意味着您不必重新编译解决方案，也不必提供其他服务。
此外，其他消费者不必改变任何东西。
虽然它对外部语言没有帮助，但是可以为命名空间设置别名（假设类Project与具有属性Project的类位于不同的命名空间中），如下所示：
using ns = MyProject.Namespace;
然后你只需要这样做：
var newProject = new ns.Project();
WTF在一种语言中的变量名称与Web服务有关吗？
有人必须非常懒惰他们的XML绑定，以便在线上公开实现细节。
WSDL / SOA的重点在于您有一个与实现无关的消息规范。 如果从源代码生成消息规范，或者从规范生成源而不允许生成对象的变化，则最终会得到紧密耦合的系统。 这种紧密耦合的一个症状是获得不是合法标识符的变量/属性名称。 服务（而不是RPC）没有紧密耦合。 您不必更改服务实现以满足服务的实现 – 如果必须，您的堆栈中的某些内容会被破坏。 这适用于成员变量/属性以及方法。