WCF: Exponiendo las propiedades de readonly DataMember sin set?

Ponga el atributo DataMember en un campo que no sea la propiedad.

Recuerde pensamiento, que WCF no sabe encapsulación. Encapsulación es un término OOP, no un término SOA.

Dicho esto, recuerde que el campo solo se leerá a las personas que usen su clase - cualquiera que use el servicio tendrá acceso completo al campo de su lado.

Tenía algunas propiedades en una clase en mi capa de servicio que quería pasar a Silverlight. No quería crear una nueva clase.

No realmente 'recomendado', pero este parecía el menor de los dos males para pasar por encima de la propiedad Total a silverlight (únicamente para el enlace visual de datos).

public class PricingSummary
{
    public int TotalItemCount { get; set; } // doesnt ideally belong here but used by top bar when out of store area

    public decimal SubTotal { get; set; }
    public decimal? Taxes { get; set; }
    public decimal Discount { get; set; }
    public decimal? ShippingTotal { get; set; }
    public decimal Total
    {
        get
        {
            return + SubTotal
                   + (ShippingTotal ?? 0)
                   + (Taxes ?? 0)
                   - Discount;
        }
        set
        {
            throw new ApplicationException("Cannot be set");
        }
    }
}

Hay una manera de lograr esto. Pero tenga en cuenta que viola directamente el siguiente principio citado en esta respuesta :

"3. Los servicios comparten esquema y contrato, no clase."

Si esta violación no te concierne, esto es lo que haces:{[12]]}

1. Mueva los contratos de servicio y datos a una biblioteca de clases separada (portátil). (Llamemos a esta asamblea SomeService.Contracts.) Así es como definirías un [DataContract] clase:

   namespace SomeService.Contracts
   {
       [DataContract]
       public sealed class Foo
       {
           public Foo(int x)
           {
               this.x = x;
           }
   
           public int X
           {
               get
               {
                   return x;
               }
           }
   
           [DataMember]  // NB: applied to the backing field, not to the property!
           private readonly int x;
       }
   }
   

   Tenga en cuenta que [DataMember] se aplica al campo de respaldo, y no a la propiedad de solo lectura correspondiente.

2. Haga referencia al ensamblaje del contrato tanto de su proyecto de aplicación de servicio (llamaré al mío SomeService.Web) como de sus proyectos cliente (el mío se llama SomeService.Client). Esto podría resultar en las siguientes dependencias del proyecto dentro de su solución:

   

3. A continuación, cuando agregue la referencia de servicio a su cliente proyecto, asegúrese de tener la opción "tipos de reutilización" habilitada, y asegúrese de que su ensamblaje de contrato (SomeService.Contracts) se incluirá en esto:

   

Voilà! Visual Studio, en lugar de generar un nuevo tipo Foo a partir del esquema WSDL del servicio, reutilizará el tipo Foo inmutable de su ensamblaje de contrato.

Una última advertencia: Ya se ha desviado de los principios de servicio citados en esa otra respuesta . Pero trata de no alejarte más. Usted podría sentirse tentado a comenzar a agregar lógica (de negocios) a sus clases de contrato de datos; no lo haga. Deben mantenerse lo más cerca posible de los objetos de transferencia de datos (DTO) tontos que pueda administrar.

Definir el contrato de servicio (Interfaz) Antes de implementar el contrato utilizando la clase.