14 votes

Que faire lorsque le nom de la propriété correspond au nom de la classe

Dans notre code C#, nous avons une classe appelée Project. Notre classe de base BusinessObject (dont tous les objets d'entreprise héritent) définit une propriété :

public Project Project { get; set; }

Ce n'est normalement pas un problème tant que l'on reste dans la base de code C#. Toutefois, ces classes d'objets d'entreprise sont exposées dans des services Web par l'intermédiaire de câbles. Certains langages de consommation (tels que Flex's actionscript) ne peuvent pas gérer le fait qu'une propriété porte le même nom que sa classe.

Ce conflit de noms se produit partout dans notre code. Parfois, il est facile de changer le nom de la propriété ou de la classe. Parfois, c'est vraiment difficile. Nous nous sommes creusé les méninges et n'avons pas réussi à trouver une bonne méthode standard pour gérer ce problème. Il est possible de renommer la classe Project en ProjectType ou ProjectInfo, mais c'est laid et cela casse tout le code existant de nos consommateurs. Nous pourrions laisser le nom du type inchangé et changer le nom de la propriété en ProjectInfo, mais cela pose le même problème.

Quelqu'un a-t-il des conseils ou des meilleures pratiques pour une telle situation ?

EDITAR:

En répondant à certaines des suggestions formulées :

  • Les méthodes ne sont pas exposées sur le fil, donc on ne peut pas les utiliser.
  • Je préférerais une convention de dénomination standard qui respecte également les normes de dénomination propres à Microsoft.
  • L'exposition d'un contrat différent pour Flex peut être une option. Cependant, nous utilisons Weborb pour l'interopérabilité avec Flex. Weborb utilise la réflexion pour faire correspondre exactement les noms de propriété, plutôt que d'utiliser la sérialisation XML ou SOAP. Si quelqu'un en sait plus sur la sérialisation personnalisée avec Weborb, ce serait utile.

EDIT #2 :

Pour référence, nous avons fini par renommer la propriété en quelque chose comme :

public Project ProjectInfo { get; set; }

4voto

Jon Skeet Points 692016

On dirait que vous avez un problème insoluble si vous avez déjà le service web avec le nom problématique. Si vous ne pouvez rien changer sans briser les clients existants, et si vous ne pouvez pas laisser les choses en l'état sans briser Flex, de quelqu'un va être cassé.

Vous pourrait exposer potentiellement une API parallèle à une URL différente. Je suis d'accord avec la suggestion de shahkalpesh concernant les méthodes Get/Set lorsque les propriétés posent problème. Ce qui est bien, c'est que vous pouvez prendre la décision suivante une fois et ensuite être cohérent plutôt que de devoir y penser à chaque fois. Cela signifie également que vous pouvez probablement automatiser la création de la deuxième API en fonction de la première.

2voto

Chris Marisic Points 11495

Je pense que la meilleure solution est de refactoriser votre projet pour renommer l'objet Project en quelque chose d'autre : WnProject, ProjectBase, ou quelque chose d'autre en rapport avec ce qu'est exactement le projet.

Il s'agit de votre API, toute personne qui la consomme doit comprendre qu'il est possible d'avoir des changements cassants expédiés, c'est le coût d'être dépendant de sources externes.

0voto

ChrisW Points 37322

J'utilise camelCase au lieu de UpperCase pour le nom des membres (méthodes et propriétés).

Cependant, comme cela va à l'encontre des conventions de dénomination standard, je ne peux pas parler de "meilleure pratique" (mais c'est ce que j'aime).

Donc, dans votre exemple, je définirais.. :

Project project { get; set; }

0voto

shahkalpesh Points 21553

Et les bonnes vieilles méthodes ? (GetProject/SetProject OU la façon dont .net le fait - Thread.CurrentThread)

0voto

Nullius Points 185

Je sais que c'est une vieille question, mais elle pourrait aider d'autres personnes.

Pourquoi ne pas fournir un WSDL différent pour les consommateurs qui ne supportent pas le même nom et type de prop ?
Renommer le complextype dans le WSDL (PAS le nom de l'élément !)

De ce que vous (devriez) avoir maintenant :

<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>

A :

<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>

Dans ce cas, le message SOAP reste exactement le même, ce qui signifie que vous n'avez pas à recompiler votre solution ni à fournir un autre service.
De plus, les autres consommateurs n'auront pas à changer quoi que ce soit.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X