c# - objetos - Qué hacer cuando el nombre de la propiedad coincide con el nombre de la clase

objetos dinamicos c#

Question

En nuestro código C #, tenemos una clase llamada Proyecto. Nuestra clase base BusinessObject (de la que heredan todos los objetos comerciales) define una propiedad:

public Project Project { get; set; }

Esto normalmente no es un problema siempre que permanezcamos dentro de la base de código C #. Sin embargo, estas clases de objetos comerciales están expuestas en los servicios web a través del cable. Algunos lenguajes de consumo (como el ActionScript de Flex) no pueden manejar tener una propiedad con el mismo nombre que su clase.

Este conflicto de nombres ocurre en todo el lugar en nuestro código. A veces es fácil cambiar el nombre de la propiedad o clase. A veces es realmente difícil. Nos hemos destrozado el cerebro y no podemos encontrar una buena forma estándar de manejar esto. Es posible cambiar el nombre de la clase Project a ProjectType o ProjectInfo, pero esto es feo y rompe todos los códigos existentes de nuestros consumidores. Podríamos dejar el nombre del tipo igual y cambiar el nombre de la propiedad a ProjectInfo, pero esto causa el mismo problema.

¿Alguien tiene alguna guía o mejores prácticas para tal situación?

EDITAR:

Respondiendo a algunas de las sugerencias dadas:

• Los métodos no están expuestos a través del cable, por lo que no podemos usar métodos.
• Preferiría una convención de nomenclatura estándar que también se adhiera a los propios estándares de nomenclatura de Microsoft.
• Exponer un contrato diferente para Flex puede ser una opción. Sin embargo, estamos usando Weborb for Flex interoperabilidad. Weborb utiliza la reflexión para hacer coincidir exactamente los nombres de las propiedades, en lugar de usar la serialización XML o SOAP. Si alguien sabe más acerca de la serialización personalizada con Weborb, sería útil.

EDIT # 2:

Como referencia, terminamos cambiando el nombre de la propiedad a algo así como:

public Project ProjectInfo { get; set; }

Answer 1

¿Qué hay de buenos viejos métodos? (GetProject / SetProject O la forma en que lo hace .net - Thread.CurrentThread)

Answer 2

Aunque no es realmente útil para los lenguajes externos, es posible asignar un alias a los espacios de nombres (presumiendo que la clase Proyecto está en un espacio de nombres distinto a la clase con la propiedad Proyecto), así:

using ns = MyProject.Namespace;

Entonces solo tienes que hacer:

var newProject = new ns.Project();

Answer 3

Creo que la mejor solución es refactorizar su proyecto para cambiar el nombre del objeto Proyecto a algo más, WnProject, ProjectBase u otra cosa relevante para lo que es exactamente el proyecto.

Es su API, cualquiera que la consuma tiene que entender que es posible tener cambios de última hora enviados, es el costo de depender de fuentes externas.

Answer 4

Parece que tienes un problema insoluble si ya tienes el servicio web con el nombre problemático. Si no puede cambiar nada sin romper a los clientes existentes, y no puede dejarlo como está sin romper Flex, alguien se romperá.

Podría exponer una API paralela en una URL diferente. Estoy de acuerdo con la sugerencia de shahkalpesh de los métodos Get / Set donde las propiedades serían problemáticas. Lo bueno de esto es que puedes tomar la decisión una vez y luego ser constante en lugar de tener que pensar en ello cada vez. También significa que probablemente puedas automatizar la creación de la segunda API basada en la primera.

Answer 5

WTF tiene el nombre de una variable en un idioma que tiene que ver con un servicio web?

Alguien tiene que ser muy flojo en su enlace XML para que los detalles de implementación se expongan por cable.

El objetivo de WSDL / SOA es que tiene una especificación para un mensaje que es independiente de la implementación. Si genera especificaciones de mensajes a partir del código fuente o genera fuentes a partir de las especificaciones sin permitir la variación de los objetos generados, termina con sistemas estrechamente acoplados. Un síntoma de este estrecho acoplamiento es obtener nombres de variable / propiedad que no son identificadores legales. Un servicio (en lugar de un RPC) no está estrechamente acoplado. No debería tener que variar su implementación del servicio para atender la implementación del servicio, si es necesario, algo en su pila está roto. Eso se aplica a las variables / propiedades de los miembros, así como a los métodos.

Answer 6

Yo uso camelCase lugar de UpperCase , para el nombre de los miembros (métodos y propiedades).

Esto va en contra de las convenciones de nomenclatura estándar, sin embargo, así que no puedo llamarlo una "mejor práctica" (pero es lo que me gusta).

Entonces, en tu ejemplo estaría definiendo:

Project project { get; set; }

Answer 7

Sé que esta es una vieja pregunta, pero podría ayudar a otros.

¿Por qué no proporcionar un WSDL diferente para los consumidores que no son compatibles con el mismo nombre y tipo de accesorio?
Cambie el nombre del tipo de complejo en WSDL (NO el nombre del elemento!)

De lo que (deberías) tener ahora:

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

En este caso, el mensaje SOAP permanecería exactamente igual, lo que significa que no tiene que volver a compilar su solución ni proporcionar otro servicio.
Además, otros consumidores no tendrán que cambiar nada.