Una Mojca Más

Al fin y al cabo esto es solo un ejemplo ilustrativo y educativo, pero tampoco está mal hecho bajo mi parecer.

El contrato no deja de ser una definición de una interface. En este caso, para poder utilizar el servicio, necesito de una clase auxiliar: la clase Cumple. Quiero que el cliente sea capaz de instanciarla y recivirla/enviarla, así que debo ponerla en el contrato, indicando los campos quiero que el usuario vea y no vea.

En este caso he creado unas variables privadas en mi clase a las que se accede a través de sus propiedades. El cliente solo tiene que saber que la clase Cumple tiene dos propiedades públicas a las que puede acceder y editar y por eso les pongo el atributo [DataMember].

Al final solo estoy definiendo una clase como siempre lo hemos hecho, pero después indicamos qué campos de esta clase van a ser serializados en el contrato, o sea, accesibles para el cliente.

No se si me he explicado. :P

Tiene el atributo DataMember en las dos propiedades que utiliza el cliente.

Al ser propiedades, éstas deben editar alguna variable: en este caso las privadas. Yo no puedo definir dos propiedades sin que estas editen alguna variable.

Podría haver definido directamente la clase Cumple así, sin utilizar propiedades:

[DataContract]

public class Cumple

{

  [DataMember]

  public string Nombre;

  [DataMember]

  public DateTime Fecha;

}

O utilizar la nueva forma de definirlas (supongo):

[DataContract]

public class Cumple

{

  [DataMember]

  public string Nombre {get;set;}

  [DataMember]

  public DateTime Fecha {get;set;}

}

Pero he utilizado la forma básica de una propiedad:

-atributo privado:

private string nombre;

-propiedad public que accede al atributo privado:

public string Nombre

{

    get { return nombre; }

    set { nombre = value; }

}

Por eso hay los dos atributos.

Además, si creas tu un proyecto de "WCF Service Library" con Visual Studio Orcas. La misma Template te crea una clase que está marcada como DataContract que tiene propiedades como la mia, con su atributo privado:

Ejemplo de DataContract que da VS Orcas Beta 1:

[DataContract]

public class CompositeType

{

  bool boolValue = true;

  string stringValue = "Hello ";

  [DataMember]

  public bool BoolValue

  {

      get { return boolValue; }

      set { boolValue = value; }

  }

  [DataMember]

  public string StringValue

  {

      get { return stringValue; }

      set { stringValue = value; }

  }

}

Si he hecho algo mal y creéis que debo corregirlo decírmelo: ni soy un genio, ni perfecto y, como dije en mi primer post, estoy a quí para aprender e intentar compartir. Sobretodo para aprender.

Me falta mucho para llegar al nivel de muchos de los genios que hay aquí, pero con vuestra ayuda no será difícil.

gracias.

No nos hemos entendido. :P

Ya se que no estas criticando mi post, en ningún momento he sentido eso. Lo que veo es que no nos hacemos entender.

Veamos si esta vez...

Si yo no declaro los atributos privados, ¿a qué variable va a acceder la propiedad?; al fin y al cabo las propiedades son, en este caso, encapsulamientos del acceso a unas variables que me guardarán la información del nombre y la fecha. Si yo no declaro esas variables... ¿donde se guardan los datos?, en todo caso hago directamente (como en el ejemplo de antes) los atributos públicos y elimino las propiedades.

Nos entendemos ahora?

Tienes toda la razón.

Como ya he dicho en una de las respuestas yo haría las atributos públicos sin encapsularlos en propiedades, ya que en esta clase de intercambio, como bién dices, no tiene motivo.

Pero como en los primeros ejemplos de cualquier libro o en el ejemplo que te da la plantilla de Visual Studio se ponen las propiedades, he pensado que en mi ejemplo, al ser también un ejemplo fácil y didáctico, también debería ponerlas.

Pero creo que, como tienes toda la razón, mejor que ponga el ejemlo de la forma que en realidad lo hago.

Gracias por tu aportación.

Ahora mi duda es... ¿cambio el post?, si lo cambio toda esta serie de comentarios no vendrán al caso... :P

Una cosa sí que me gustaría aclarar.

Según las buenas bases de programación y demás que a mi me han enseñado (vaya, que he leído); si las clases exponen atributos al exterior (atributos públicos), éstos es mejor que sean privados y vayan encapsulados en propiedades públicas.

Y, aunque la clase Cumple en este caso forma parte de un contrato, es un DataContract, sigue siendo una clase, y, siguiendo estas "buenas prácticas", sería bueno dejar los atributos tal y como están.

Para corroborar esto se ha creado la nueva forma de declarar atributos en C#, en la version 3.5 del Framework:

public string MiPropiedad {get;set;}

Que te genera, internamente, la encapsulación.

La idea está en no exponer nunca atributos, si no propiedades.