2010-05-21 10 views
5

Tengo un servicio WCF y un cliente web. El servicio web implementa un método SubmitOrders. Este método toma una colección de órdenes. El problema es que el servicio debe devolver una matriz de resultados para cada orden - verdadero o falso. Marcar los parámetros WCF como out o ref no hace sentido . ¿Qué recomendarías?Diseño de interfaz WCF: sin parámetros de salida o referencia

[ServiceContact] 
public bool SubmitOrders(OrdersInfo) 

[DataContract] 
public class OrdersInfo 
{ 
    Order[] Orders; 
} 
+0

OK.Esto fue solo mi falta de conocimiento sobre los atributos de WCF. Gracias a todos por las respuestas. –

Respuesta

11

Marcar los parámetros WCF como out o ref no tiene sentido.

los parámetros tienen sentido en WCF.

¿Qué recomendarías?

Recomiendo utilizar los parámetros.


Nota 1: Moverá su parámetro de salida para que sea el primer parámetro en usted.

Nota 2: Sí, puede devolver objetos con tipos complejos en WCF. Etiquete su clase con un atributo de [DataContract] y sus propiedades con un atributo de [DataMember].

+0

Acepto, los hemos usado extensamente en nuestros propios servicios. También puede marcar el método como IsOneWay = False y pasar una matriz de los datos que desee a la persona que llama en lugar de simplemente un bool. –

+0

Err ... Ya veo. Pensé que WCF serializa la clase en mensajes y el mensaje se transfiere al servicio. Los parámetros de salida asumen algún mensaje de regreso al cliente del . ¿Estoy en lo cierto? –

+0

¡Simplemente no agregue OneWayAttribute! El valor predeterminado es Solicitud/Respuesta. – Erup

1

Clase especial que contiene el orden y el verdadero/falso, o una serie de tupeles.

2

Bueno, si desea evitar los parámetros de salida y ref, siempre puede devolver una matriz de los ID de los pedidos que se enviaron correctamente.

+1

@Captain: no estoy seguro acerca de WCF específicamente, pero los servicios SOAP pueden usar parámetros de "salida". Supongo que WCF lo admite, ya que tiene sentido al menos con SOAP y TCP/IP. –

1

El método se vería así:

public OrdersInfo SubmitOrders(OrderInfo orders){ 
} 

que cada elemento de Información de Pedido tendrá un SubmissionStatusInfo como:

class SubmissionStatusInfo{ 
enum Status { get; set; } 
string Message { get; set; } 
} 

donde Status : Submitted, Failed, Error etc.
Message: una cadena que da alguna información adicional sobre el estado ...

HTH

+0

Puede realizar FaultException . Es una "mejor práctica" al transmitir un error. – Erup

+0

Sí, eso tiene más sentido ... – Sunny

3

Use el tipo complejo (otra clase con el atributo DataContract) a cambio.

Como

[ServiceContact] 
public OrdersResult SubmitOrders(OrdersInfo) 

[DataContract] 
public class OrdersInfo 
{ 
    Order[] Orders; 
} 

[DataContract] 
public class OrdersResult 
{ 
    ..... 
} 

También añadir DataMember en Order[] Orders;

+0

No es necesario crear otro obj de DataContract. Solo pasa como parámetro. – Erup

+0

Ambas soluciones funcionarán. Depende del diseño si quiere tener un tipo complejo param o return. – Incognito

2

Sí, tiene sentido devolver un parámetro cabo en las operaciones de WCF. En respuesta, el mensaje SOAP contendrá el elemento devuelto.

Hay un buen contenido en MSDN sobre la transferencia de datos: Specifying Data Transfer in Service Contracts

Además, es necesario utilizar el OperationContractAttribute (no ServiceContractAttribute) en los SubmitOrders.

+0

Gracias. Esto es solo un error tipográfico. Esto no fue copiar pasta, simplemente simplifiqué el problema y escribí el código a toda prisa. –

Cuestiones relacionadas