¿Es una mala práctica tener un parámetro de salida en un método en un servicio WCF?

Question

Estoy buscando razones más allá de lo habitual "los parámetros de salida son confusos e indican que el método está haciendo más de una cosa" argumentos de estilo y más sobre lo que es específicamente malo acerca de los parámetros de salida en los servicios de WCF. Donde trabajo ahora, tenemos una regla en contra de ellos en los servicios de WCF, ¡y estoy tratando de descubrir por qué!

Answer 1

Personalmente, utilizo los parámetros en lugares específicos (como los métodos denominados TryParse()). Entonces, tengo algunos de los prejuicios de los que hablas cuando solo los uso en lugares específicos y limitados. Además, no puede suponer que una aplicación .Net va a consumir esto en el otro extremo. Debido a que WCF proporciona un consumible de interfaz como un servicio web SOAP o REST (entre otros tipos de comunicación), no puedo garantizar que WCF incluso admita parámetros para la compatibilidad con consumidores que no sean .Net.

Más allá de eso, un servicio WCF proporciona una API a un consumidor, y las API deben proporcionar una interfaz que debe consumirse con un conocimiento limitado de cómo se codificaron los métodos del servidor. (No suponga que el tipo que escribe el servidor WCF es el mismo tipo que escribe el cliente en el otro extremo). Intentar utilizar un parámetro out en una API parece un olor a código. Presumiblemente, uno usaría un param para devolver otro (s) valor (es) al consumidor. Considere en cambio usar un objeto de mensaje. Un objeto de mensaje se compone específicamente de todos los datos que deben enviarse desde el servidor WCF a su consumidor. Por ejemplo, digamos que usted tiene un método expuesto en un servidor de llamada WCF TryCreateUser:

bool TryCreateUser(string name, string email, out User user){} 

donde va a devolver un bool que indica que se produjo con éxito la creación de usuarios y un objeto de usuario que contiene el usuario si tenía éxito. Me gustaría crear una nueva clase, UserCreationMessage:

class UserCreationMessage { 
    bool IsSuccessful; 
    User user; 
} 

Retorno este objeto de mensaje de vuelta al consumidor, y todavía se puede conseguir a los múltiples valores devueltos. Sin embargo, ahora tiene devuelto un objeto coherente que es más explicativo para el usuario final de la API.

Al final, razonaría que es una mala práctica tener un parámetro de salida en una API, como un servidor WCF porque los programadores que crean el consumidor para este servicio tienen que poder ver fácilmente la API y consumir sin saltar por los aros que un param presente. Dado que existe un mejor diseño para esto, úselo. Las API requieren estándares de codificación más altos, especialmente en la interfaz expuesta al consumidor final.

Answer 2

Una de las razones es que los parámetros out son manejados por la clase de proxy generada cuando se agrega la referencia de servicio, eso es una sobrecarga adicional.

Otra razón: de acuerdo con this post, incluso si el parámetro original out es el último cuando lo consume, se convierte en primer lugar - confuso y puede conducir a errores complicados que pueden tomar tiempo para resolver hasta que alguien se dé cuenta.

Opinión personal: la operación WCF (método) debería hacer algo y devolver algo. Puede hacer muchas cosas, pero solo devuelve una cosa, que es el resultado: si necesita material adicional, simplemente devuelva el tipo complejo con todo lo que necesita como campos de datos de ese tipo.