相关疑难解决方法(0)

我有时会看到这样编写的代码:

public class B1
{
}

public class B2
{
    private B1 b1;

    public B1 B1
    {
        get { return b1; }
        set { b1 = value; }
    }
}

即,B2类具有名为"B1"的属性,其也是"B1"类型.

我的直觉告诉我这不是一个好主意,但有什么技术原因可以避免给出与其类同名的财产吗？

(我正在使用.net 2.0,以防万一).

在我们的C#代码中,我们有一个名为Project的类.我们的基础BusinessObject类(所有业务对象都继承自)定义了一个属性:

public Project Project { get; set; }

只要我们保持在C#代码库中,这通常不是问题.但是,这些业务对象类通过网络在Web服务中公开.某些消费语言(例如Flex的actionscript)无法处理具有与其类同名的属性.

这个命名冲突发生在我们代码中的所有地方.有时,更改属性或类的名称很容易.有时它真的很难.我们绞尽脑汁,无法想出一个很好的标准方法来处理这个问题.可以将Project类重命名为ProjectType或ProjectInfo,但这很丑陋并且会破坏我们所有消费者的现有代码.我们可以保留类型名称相同并将属性的名称更改为ProjectInfo,但这会导致相同的问题.

有没有人对这种情况有任何指导或最佳做法？

编辑:

回应一些建议:

• 方法不会通过电线暴露,因此我们不能使用方法.
• 我更喜欢标准的命名约定,它也符合微软自己的命名标准.
• 可以选择为Flex公开不同的合同.但是,我们正在使用Weborb for Flex interop.Weborb使用反射来精确匹配属性名称,而不是使用XML或SOAP序列化.如果有人对Weborb的自定义序列化有更多了解,那将会很有帮助.

编辑#2:

作为参考,我们最终将属性重命名为:

public Project ProjectInfo { get; set; }