Múltiples Proyectos WCF vs Proyecto Único en la Solución

Question

Actualmente tenemos 12 proyectos WCF en nuestra solución. Cada proyecto es esencialmente su propio punto final. Por ejemplo, el proyecto WCF "Order" es el punto final Order.svc. Estos 12 puntos finales están expuestos por un único proyecto WebHost. El proyecto WebHost tiene 12 archivos .svc apuntando a cada ensamblado/espacio de nombres correspondiente.

Mi pregunta gira en torno al uso de UN proyecto (un conjunto ... un dll) frente a varios proyectos (conjuntos múltiples ... múltiples dlls). ¿Cuáles son las ventajas/desventajas, si las hay? El resultado final es el mismo ... usted tiene un proyecto WebHost que expone estos puntos finales apuntando a un ensamblado/espacio de nombres. Excepto que solo tiene que administrar un .dll contra 12 .dll en el directorio bin.

Para mí las ventajas de un proyecto: Mantenibilidad: en lugar de 12 proyectos, cada uno con múltiples referencias a nuestras interfaces, datos, utilidad, etc., tenemos un proyecto que tiene las referencias establecidas en UN lugar. Entonces podemos desplegar el dll y utilizar un equilibrador de carga para distribuir de manera uniforme. Incluso si alojamos explícitamente 3 servicios por servidor (por lo tanto, 4 servidores), si un servidor deja de funcionar, el equilibrador de carga puede ajustarse y los otros 3 servidores tendrán lo que necesitan y se encargarán de todo de manera automágicamente. (Supongo que lo mismo es cierto con 12 .dll ... solo hay que asegurarse de que los 12 .dll estén en cada servidor).

Tiempo de compilación: menos proyectos = tiempo de compilación más rápido. Visual Studio no tiene que realizar tanta vinculación y copia de .dll en todo el lugar. Tiempo de construcción más rápido = desarrollador más productivo y una compilación e implementación más rápida.

Actualmente tengo un par de compañeros de trabajo preocupados por "acoplar estrechamente" todos nuestros servicios de WCF en un solo proyecto. Para mí, todos son servicios de WCF ¿por qué no ponerlos en el mismo proyecto? Los puntos finales (archivos .svc) son lo que los separa. También he escuchado la pregunta, "¿qué pasa con el bloqueo muerto?". ¿Qué hay de eso? ¿Es eso un problema/preocupación válida? (Honestamente, no lo sé)

También ha habido preguntas sobre si el .dll se daña. SI lo es, entonces todos los servicios están caídos. De nuevo ... ¿es esto una preocupación válida?

Todos los ejemplos que he visto de Microsoft y otros tienen los servicios de WCF en un proyecto separados por diferentes clases. Las interfaces están en su propio proyecto ... los contactos de datos en otro proyecto, etc.

Entonces, ¿cuál es su opinión? ¿Cómo se organizan múltiples servicios WCF en su solución Visual Studio? Aprende de mi.

Answer 1

Aprendimos esto de la manera difícil. Recientemente tuvimos un proyecto en el que comenzamos con cada servicio en su propio proyecto y terminamos convirtiéndonos para tener todos los servicios en el mismo proyecto. Los principales problemas para tener cosas en diferentes proyectos son:

• Despliegue: ¿Crea paquetes de 12 msi uno para cada servicio? ¿Se implementarán en sitios web separados? ¿Qué piensa opperations sobre la ejecución de 12 scripts de instalación y la supervisión de 12 sitios?
• ¿Los servicios se llaman entre sí, si es así, entonces sobre WCF puede ser lento y la configuración puede ser una pesadilla, 12 servicios que llaman a 11 servicios, con configuración para dev, test y prod.
• También en servicios que se llaman entre sí hay un golpe de rendimiento en comparación con una llamada dll directa
• ¿Los servicios tienen una versión común, cuando por ejemplo cambia la base de datos todos los servicios cambiarán. En caso afirmativo, siempre tendrá que implementar todos los servicios.Esto lleva más tiempo que un solo servicio, su tiempo de inactividad será más largo

Utilizamos proyectos separados para objetos Interfaces (contratos) y transferencia de datos.

Answer 2

Generalmente, si mis archivos svc existen en el mismo ensamblado, entonces están compartiendo algún propósito. Si el svc comparte suficiente propósito común para existir en el mismo ensamblado, entonces la implementación también comparte suficiente propósito común para existir en un solo ensamblaje.

No hay ningún problema con tenerlos en ensamblajes separados, pero tampoco hay ningún beneficio. Se trata más bien de construir una solución claramente estructurada y mantenible, y es en gran medida una cuestión personal de preferencias/estándares/estilo.

Separe las implementaciones si normalmente las separaría, es decir, si dan resultados significativamente diferentes o si actúan como componentes separados de su solución. Si el conjunto único sería difícil de manejar, sepárelo.

Enfóquese más en contratos e implementaciones. Sirven para fines diferentes (técnicos) y es posible que desee exponer los contratos sin exponer las implementaciones.

Habiendo dicho todo eso, preferiría tenerlos en un solo ensamblaje pero separados por espacios de nombres claros. Menos montajes a menudo es más fácil de administrar.

Answer 3

Recuerde, no tiene que implementar sus proyectos de la misma manera que administra su desarrollo. Siempre puede usar cosas como ILMerge para mutiple dlls en una dll, como parte de un paso de compilación.

Siempre recomiendo desarrollar algunos servicios usando Software Factory (también conocido como Web Service Software Factory), http://servicefactory.codeplex.com/ que ayuda a aplicar un conjunto de "mejores prácticas" del equipo de Prácticas MSFT Patterns &. Es una excelente forma de aprender algunas de las mejores prácticas, pero una vez que las aprende, generalmente es mejor/más fácil hacerlas cumplir mediante buenas revisiones de guía/código con su equipo de desarrollo. De esta forma puede usar lo que funciona en su entorno y no usar lo que se interpone en el camino.

Si tiene 12 servicios, ¿cómo maneja la configuración que puede ocurrir? Especialmente cuando tiene servicios que dependen de otros servicios. Eventualmente, poner todo eso, y cualquier enlace y comportamiento personalizado, en la configuración puede ser una pesadilla de implementación. Además, ¿cómo hace que sus servicios sean conocidos por otros en la empresa? ¿Todo se hace de boca en boca, una buena administración de compilación y control de fuente?