在我们的 C# 代码中,有一个名为 Project 的类。我们的基础 BusinessObject 类(所有业务对象都继承自它)定义了一个属性:
在我们的代码中,这种命名冲突随处可见。有时更改属性或类的名称很容易。有时则非常困难。我们已经竭尽全力,无法想出一个有效的标准方法来处理此问题。可以将 Project 类重命名为 ProjectType 或 ProjectInfo,但这很丑陋并且会破坏所有消费方现有的代码。我们可以将类型名称保持不变,并将属性名称更改为 ProjectInfo,但会导致相同的问题。
是否有任何指导或最佳实践可以应对这种情况?
编辑:
回应一些给出的建议:
- 方法不会公开,因此我们无法使用方法。 - 我希望有一个符合 Microsoft 自己命名规范的标准命名约定。 - 为 Flex 公开不同的合同可能是一个选项。但是,我们正在使用 Weborb 进行 Flex 互操作性。Weborb 使用反射完全匹配属性名称,而不是使用 XML 或 SOAP 序列化。如果有人了解有关使用 Weborb 进行自定义序列化的更多信息,那将非常有帮助。
第二次编辑:
供参考,我们最终将属性重命名为类似以下内容:
public Project Project { get; set; }
只要我们在 C# 代码库中保持不变,这通常不是问题。但是,这些业务对象类在 web 服务中公开。一些使用语言(例如 Flex 的 actionscript)无法处理具有与其类相同名称的属性。在我们的代码中,这种命名冲突随处可见。有时更改属性或类的名称很容易。有时则非常困难。我们已经竭尽全力,无法想出一个有效的标准方法来处理此问题。可以将 Project 类重命名为 ProjectType 或 ProjectInfo,但这很丑陋并且会破坏所有消费方现有的代码。我们可以将类型名称保持不变,并将属性名称更改为 ProjectInfo,但会导致相同的问题。
是否有任何指导或最佳实践可以应对这种情况?
编辑:
回应一些给出的建议:
- 方法不会公开,因此我们无法使用方法。 - 我希望有一个符合 Microsoft 自己命名规范的标准命名约定。 - 为 Flex 公开不同的合同可能是一个选项。但是,我们正在使用 Weborb 进行 Flex 互操作性。Weborb 使用反射完全匹配属性名称,而不是使用 XML 或 SOAP 序列化。如果有人了解有关使用 Weborb 进行自定义序列化的更多信息,那将非常有帮助。
第二次编辑:
供参考,我们最终将属性重命名为类似以下内容:
public Project ProjectInfo { get; set; }