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

Question

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

Answer 1

Bien que cela ne soit pas vraiment utile pour les langues externes, il est possible d'aliaser les espaces de noms (en supposant que la classe Project se trouve dans un espace de noms différent de celui de la classe avec la propriété Project), comme suit :

using ns = MyProject.Namespace;

Alors tu dois juste faire :

var newProject = new ns.Project();

Answer 2

Qu'est-ce que le nom d'une variable dans une langue a à voir avec un service web ?

Il faut que quelqu'un soit vraiment paresseux dans sa liaison XML pour que les détails de mise en œuvre soient exposés sur le fil.

L'intérêt de WSDL/SOA est de disposer d'une spécification pour un message qui est indépendant de la mise en œuvre. Si vous générez des spécifications de messages à partir du code source, ou si vous générez le code source à partir des spécifications sans permettre la variation des objets générés, vous vous retrouvez avec des systèmes étroitement couplés. Un symptôme de ce couplage étroit est l'obtention de noms de variables/propriétés qui ne sont pas des identifiants légaux. Un service (plutôt qu'un RPC) n'est pas étroitement couplé. Vous ne devriez pas avoir à modifier l'implémentation de votre service pour tenir compte de l'implémentation du service - si vous devez le faire, c'est que quelque chose dans votre pile est cassé. Cela vaut pour les variables/propriétés membres comme pour les méthodes.