ejemplos - wcf vs rest

¿Qué mejores prácticas de WCF sigues en el diseño de modelos de objetos?

Question

Me he dado cuenta de que un puñado de aplicaciones WCF eligen "romper" sus objetos; es decir, un proyecto puede tener un ensamblado DataObjects que contenga DataContracts / Members además de una biblioteca de clases significativa que realice la lógica de negocios.

¿Es este un nivel innecesario de abstracción? ¿Hay algún mal inherente asociado con el proceso de etiquetar bibliotecas de clases existentes con información de DataContract?

Además, como un aparte, ¿cómo manejas las condiciones de error? ¿Se han aceptado generalmente algunas excepciones del servicio (InvalidOperation, ArgumentException, etc.) o existe un nivel similar?

Answer 1

La razón principal para separar los objetos comerciales internos de los contratos de datos / contratos de mensajes es que no desea que los cambios internos en su aplicación cambien necesariamente el contrato de servicio. Si está creando servicios web versionados (con más de una versión de las interfaces implementadas), a menudo tiene una versión única de sus objetos comerciales de aplicaciones con más de una versión de los objetos de contrato de datos / contrato de mensajes.

Además, en situaciones complejas de Integración Empresarial, a menudo tiene un formato de datos canónicos (contratos de Datos y Mensajes) que es compartido por varias aplicaciones, lo que obliga a cada aplicación a mapear el formato de datos canónicos a su modelo de objetos interno.

Si desea una herramienta que le ayude con los detalles de separar el contrato de contrato / mensaje de datos, etc., consulte la fábrica de software de servicios web de Microsoft http://msdn.microsoft.com/en-us/library/cc487895.aspx que tiene algunos buenas recetas para resolver la fontanería WCF.

Con respecto a excpetions, WCF automáticamente envuelve todas las excepciones en FaultExceptions, que se serializan como fallas de formato de cable.

También es posible lanzar Excepciones de falla genéricas que le permiten especificar detalles adicionales que se incluirán con la falla serializada. Dado que las fallas producidas por una operación de servicio web son parte de su contrato, es una buena idea declarar las fallas en la declaración de operación:

[FaultContract(typeof(AuthenticationFault))]
[FaultContract(typeof(AuthorizationFault))]
StoreLocationResponse StoreLocation(StoreLocationRequest request);

Tanto los tipos de AuthenticationFault como AuthorizationFault representan los detalles adicionales que se serializarán y enviarán a través del cable y se pueden lanzar de la siguiente manera:

throw new FaultException<AuthenticationFault>(new AuthenticationFault());

Si quieres más detalles, grita; He estado viviendo y respirando esto durante tanto tiempo que casi me gano la vida haciéndolo;)