怎么办时，属性名相匹配的类名 [英] What to do when property name matches class name

问题描述

在我们的C＃代码，我们有一个名为Project类。我们的基础类BusinessObject的（所有业务对象继承）定义了一个属性：

 公共工程项目{搞定;组; } 
  

这只要我们留在C＃代码库中通常是没有问题的。然而，这些业务对象类在web服务通过线路露出。有些耗时语言（如Flex的动作）不能处理具有相同的名称作为其类的属性。

这命名冲突发生遍布在我们的代码的地方。有时很容易更改的属性或类的名称。有时候真的很难。我们已经毁坏我们的大脑并不能拿出来处理一个很好的标准方式。这是可能的重命名项目类项目类型或ProjectInfo，但是这是丑陋的，打破了我们所有的消费者现有的代码。我们可以离开类型名称相同，并更改属性ProjectInfo的名字，但是这会导致同样的问题。

有没有人有这样的任何指导或最佳实践？一个情况

编辑：

在回答一些给出的建议：

• 方法不暴露在电线，所以我们不能使用的方法。


• 我宁愿一个标准的命名会议还坚持微软自己的命名标准。


• 暴露Flex的不同的合同可能是一种选择。但是，我们使用的WebORB Flex的互操作。的WebORB使用反射来精确匹配属性名称，而不是使用XML或SOAP序列化。如果有人知道更多关于的WebORB自定义的序列，这将是有益

编辑＃2：

有关参考，我们结束了物业重命名为这样的：

 公共工程ProjectInfo {搞定;组; } 
  

解决方案

这听起来像你有一个棘手的问题如果你已经有问题的名称得到了Web服务在那里。如果你不能没有打破现有的客户改变什么，你不能离开它，因为它是不破的Flex，的谁家的将被打破。

您的可能的可能在不同的URL暴露平行的API。我会用get / set方法，其中属性是有问题shahkalpesh的建议达成一致。这个的好处是，你可以做出决定的一次的，然后是一致而不需要每次都去想它。这也意味着你可能可以自动根据第一，第二API的创建。

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.

EDIT #2:

For reference, we ended up renaming the property to something like:

public Project ProjectInfo { get; set; }

解决方案

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.

这篇关于怎么办时，属性名相匹配的类名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！