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

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

public Project Project { get; set; }

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

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

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

EDIT:

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

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

ИЗМЕНИТЬ № 2:

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

public Project ProjectInfo { get; set; }

Ответы

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Project project { get; set; }

Ответ 4

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

Ответ 5

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

Почему бы не предоставить другой WSDL для потребителей, которые не поддерживают одно и то же имя и тип?
Переименуйте complextype в 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>

To:

<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-сообщение останется таким же, что означает, что вам не нужно перекомпилировать свое решение и не предоставлять другую услугу.
Кроме того, другим потребителям не придется ничего менять.

Ответ 6

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

using ns = MyProject.Namespace;

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

var newProject = new ns.Project();

Ответ 7

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

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

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