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

Question

He notado que un puñado de aplicaciones WCF optan por "separar" sus objetos;es decir, un proyecto podría tener un ensamblado de DataObjects que contenga contratos de datos/miembros además de una biblioteca de clases significativa que realice lógica empresarial.

¿Es este un nivel innecesario de abstracción?¿Existe algún mal inherente asociado con revisar y etiquetar bibliotecas de clases existentes con información de DataContract?

Además, aparte, ¿cómo se manejan las condiciones de error?¿Se aceptan generalmente las excepciones lanzadas por el servicio (InvalidOperation, ArgumentException, etc.), o suele haber un nivel en torno a eso?

Answer 1

La razón clave 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 tendrá una única versión de los objetos comerciales de sus aplicaciones con más de una versión de los objetos de contrato de datos/mensaje.

Además, en situaciones complejas de integración empresarial, a menudo se tiene un formato de datos canónicos (contratos de datos y mensajes) que comparten varias aplicaciones, lo que obliga a cada aplicación a asignar el formato de datos canónicos a su modelo de objetos interno.

Si desea una herramienta que le ayude con el meollo de la cuestión de separar el contrato de datos/contrato de mensaje, etc.luego consulte la Fábrica de software de servicios web de Microsoft http://msdn.microsoft.com/en-us/library/cc487895.aspx que tiene algunas buenas recetas para resolver la plomería WCF.

En lo que respecta a las excepciones, WCF envuelve automáticamente todas las excepciones en FaultExceptions, que se serializan como fallas de formato de cable.

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

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

Tanto el tipo AuthenticationFault como el AuthorizationFault representan los detalles adicionales que se serializarán y enviarán por cable y se pueden generar de la siguiente manera:

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

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