WCF Contratos de datos y uso compartido de entradas

Question

Actualmente tenemos un servicio WCF que se ha configurado con sus propios DataContracts para las enumeraciones. Luego tenemos una capa de mapeo entre los Enumeradores de DataContract y los Enumedes comunes disponibles en nuestra capa de negocios. Lo mismo sucede en el extremo del cliente: una capa de mapeo entre el cliente Enum y el contrato de datos Enum

Hemos estado hablando esta mañana acerca de exponer nuestras enumeraciones comunes a través del servicio WCF y luego al cliente y no sabemos si esta es una mejor práctica o no. Por lo tanto, esta pregunta se reduce a si es bueno permitir un corte transversal de las preocupaciones por enumeraciones que provienen de nuestro back-end, a través de un servicio y en un sistema cliente o si deberíamos mantener nuestros contratos de datos separados de nuestra biblioteca de código base. . estamos tratando de lograr una mejor práctica SOA para nuestro servicio.

¿Cuáles son los pensamientos de las personas sobre esto?

Answer 1

Si desea las mejores prácticas, la configuración actual parece bastante razonable: puede administrar las versiones y otras validaciones/asignaciones en el límite con bastante facilidad con una capa DTO separada.

Esto se aplica doblemente si tiene una capa DTO completa en el límite (en lugar de exponer sus entidades de dominio regulares/transaccionales en el límite), lo cual suena como podría ser.

El inconveniente es un mayor mantenimiento, pero los hace muy flexibles y evita cualquier problema inesperado. Por ejemplo, no se aplica generalmente a WCF, pero un error clásico con los servicios web regulares es agregar un constructor no predeterminado (eliminando así el constructor predeterminado generado por el compilador). Oops! no más servicio web. Hay un tema similar de errores causados ​​por cambios inocentes que pueden evitarse separando los DTO.

Answer 2

Iría por tener una enumeración de contrato de datos separada en el nivel de servicio que se asigna a BL enum desde la compatibilidad de versión POV. Esto permitirá en el futuro mantener los mismos valores de enum de servicio e interpretación incluso si los valores enum de BL cambian. Por ejemplo, puede comenzar con 4-5 valores iguales (de 0, 1, 2, 3, 4) tanto a nivel de servicio como de negocio. En el futuro, decidió modificar el enum de negocio a una interpretación basada en indicador, por lo que tener una enumeración de servicios por separado permitirá asignar esos valores a los nuevos valores de enumeración comercial (esperando que la misma interpretación esté disponible en ese nivel), para el ejemplo 3 ahora obtener un mapa de 8 en la enumeración de negocios.

Answer 3

Actualmente estoy en la misma situación. Una solución es tener otra capa delgada a la que pueda llamar ServiceManager. Los métodos en esta capa aceptan las enumeraciones del contrato de datos, luego esto convierte el tipo de enum del contrato de datos a un tipo de enumeración BL al llamar a los métodos BL.

Pero he decidido que mi solución es eliminar las enumeraciones del contrato de datos y simplemente usar constantes de cadena.

Por favor, comparta si tiene una mejor solución.