Что делать, когда имя свойства совпадает с именем класса

Question

В нашем C # -коде есть класс Project. Наш базовый класс BusinessObject (от которого наследуются все бизнес-объекты) определяет свойство:

public Project Project { get; set; }

Обычно это не проблема, пока мы остаемся в кодовой базе C #. Однако эти классы бизнес-объектов предоставляются через веб-службы по проводам. Некоторые потребляющие языки (такие как сценарий действия Flex) не могут обрабатывать наличие свойства с тем же именем, что и его класс.

Этот конфликт имен происходит повсеместно в нашем коде. Иногда легко изменить имя свойства или класса. Иногда это действительно сложно. Мы сломали наши мозги и не можем придумать хороший стандартный способ справиться с этим. Можно переименовать класс Project в ProjectType или ProjectInfo, но это уродливо и нарушает весь существующий код наших потребителей. Мы могли бы оставить имя типа одинаковым и изменить имя свойства на ProjectInfo, но это вызывает ту же проблему.

Есть ли у кого-нибудь какие-либо рекомендации или рекомендации для такой ситуации?

EDIT:

Ответ на некоторые из приведенных предложений:

• Методы не передаются по проводам, поэтому мы не можем использовать методы.
• Я бы предпочел стандартное соглашение об именах, которое также соответствует собственным стандартам имен Microsoft.
• Может быть возможным выставление другого контракта для Flex. Однако мы используем Weborb для взаимодействия Flex. Weborb использует отражение для точного соответствия имен свойств, а не с использованием сериализации XML или SOAP. Если кто-нибудь знает больше о пользовательской сериализации с Weborb, это было бы полезно.

РЕДАКТИРОВАТЬ # 2:

Для справки мы переименовали свойство в что-то вроде:

public Project ProjectInfo { get; set; }

Answer 1

Похоже, у вас есть неразрешимая проблема, если у вас уже есть веб-сервис с проблемным именем. Если вы не можете ничего изменить, не нарушив существующих клиентов, и не можете оставить все как есть, не нарушив Flex, чей-то будет сломан.

Вы могли бы потенциально выставить параллельный API по другому URL. Я бы согласился с предложением Шахкальпеша о методах Get / Set, где свойства были бы проблематичными. Хорошая вещь в этом заключается в том, что вы можете принять решение один раз и затем быть последовательным, а не думать об этом каждый раз. Это также означает, что вы, вероятно, можете автоматизировать создание второго API на основе первого.

Answer 2

Я думаю, что лучшим решением является рефакторинг вашего проекта для переименования объекта Project во что-то еще WnProject, ProjectBase или что-то еще, относящееся к тому, что именно является проектом.

Это ваш API, любой, кто потребляет его, должен понимать, что можно получить критические изменения, это цена зависимости от внешних источников.

Answer 3

Я знаю, что это старый вопрос, но он может помочь другим.

Почему бы не предоставить другой WSDL для потребителей, которые не поддерживают одно и то же имя и тип реквизита?
Переименуйте составной тип в WSDL (НЕ имя элемента!)

Из того, что вы (должны) теперь иметь:

<xs:element name="Project" type="Project"/>

<xs:complexType name="Project">
  <xs:sequence>
    <xs:element name="Title" type="xs:string"/>
    <xs:element name="Description" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

Кому:

<xs:element name="Project" type="ProjectType"/>

<xs:complexType name="ProjectType">
  <xs:sequence>
    <xs:element name="Title" type="xs:string"/>
    <xs:element name="Description" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

В этом случае SOAP-сообщение останется прежним, то есть вам не придется перекомпилировать свое решение или предоставлять другую услугу.
Кроме того, другим потребителям ничего не придется менять.

Answer 4

Хотя это не очень помогает для внешних языков, возможно псевдоним пространств имен (предполагая, что класс Project находится в пространстве имен различий с классом со свойством Project), например так:

using ns = MyProject.Namespace;

Тогда вам просто нужно сделать:

var newProject = new ns.Project();

Answer 5

WTF имеет имя переменной на одном языке, имеющее отношение к веб-сервису?

Кто-то должен быть очень ленив в своей привязке XML для подробностей реализации, которые будут доступны в сети.

Весь смысл WSDL / SOA в том, что у вас есть спецификация для сообщения, которая не зависит от реализации. Если вы генерируете спецификации сообщений из исходного кода или генерируете источники из спецификаций, не допуская изменения сгенерированных объектов, вы получите тесно связанные системы. Одним из признаков такой тесной связи является получение имен переменных / свойств, которые не являются допустимыми идентификаторами. Сервис (а не RPC) не тесно связан. Вам не нужно изменять реализацию службы, чтобы обеспечить реализацию службы - если это необходимо, что-то в вашем стеке сломано. Это касается переменных / свойств членов, а также методов.

Answer 6

Как насчет старых добрых методов? (GetProject / SetProject ИЛИ как это делает .net - Thread.CurrentThread)

Answer 7

Я использую camelCase вместо UpperCase для имени членов (методы и свойства).

Однако это противоречит стандартным соглашениям об именах, поэтому я не могу назвать это «лучшей практикой» (но это то, что мне нравится).

Итак, в вашем примере я бы определил:

Project project { get; set; }