WCF Serialización con herencia de objeto?

Question

Tengo dos objetos, uno en nuestro nivel empresarial y otro en nuestro nivel de servicio. El objeto de servicio hereda de la empresa. Aquí está un ejemplo rápido:

[DataContract] 
public class EnterpriseObject{ 
    [DataMember] 
    int ID{get; set;} 

    string InternalUse{get; set;} 
} 

[DataContract] 
public class ServiceObject: EnterpriseBaseObject{ 
    [DataMember]  
    string Address{get; set;} 
} 

¿Es posible solamente exponer la ServiceObject (con propiedades heredadas de EnterpriseObject) en la serialización? No quiero que el cliente vea el objeto de empresa enumerado como una opción? Como puede ver en el ejemplo, el atributo DataMember no está configurado para la propiedad InternalUser. ¿Es esa la única manera de hacerlo? Gracias

Answer 1

Usted maneja la herencia agregando un [KnownType(typeof(ServiceObject))] a EnterpriseBaseObject - sin embargo, el EnterpriseBaseObject todavía es parte del contrato, y su existencia será pública. Pero solo se publicarán los miembros marcados [DataMember].

Una opción (para eliminar la herencia) es tener un DTO separado para fines de serialización, y tener una conversión entre la versión DTO y la versión real, pero eso hace que el trabajo sea adicional.

Answer 2

¿Se puede cambiar esto de un patrón Is A a un patrón Has A? Si ServiceObject tiene un EnterpriseObject, puede exponer solo las propiedades que necesita.

Editar

Si he entendido bien que desea exponer ServiceObject a los clientes, incluyendo todas sus propiedades (que están marcados como DataMember) incluyendo las propiedades heredadas de EnterpriseObject. Pero no desea que el cliente sepa que hay un objeto llamado EnterpriseObject.

Puede hacerlo ocultando el hecho de que hay un objeto empresarial. En lugar de utilizar una relación "Es A", que es un patrón de herencia. Puede usar una composición o un patrón "Tiene A".

public class ServiceObject 
{ 
    private EnterpriseObject _myEntObject; 

    public string MyServiceObjectProperty 
    { 
     get; 
     set; 
    } 

    public string MyEntObjectProperty 
    { 
    get { return _myEntObject.MyEntObjectProperty;} 
    } 
} 

Ahora ha aislado su EnterpriseObject de su cliente. Toda su comunicación es que ServiceObject tiene algunas propiedades que no está exponiendo a su cliente que este implementado en el servidor por algún otro objeto.

Esto también es similar a tener un DTO, que es un objeto que tiene como único propósito transmitir datos. Los DTO le permiten ocultar su implementación al brindar a sus clientes exactamente lo que necesitan en el formato que necesitan, sin exponer sus objetos internos.