Reutilización basada en servidor: ¿DLL, GAC o REST?

Question

Tenemos una funcionalidad que utilizan varias aplicaciones diferentes (clientes) en el mismo servidor. Se puede modelar mejor como un servicio, tiene una base de datos de back-end y solo habrá una versión de la funcionalidad y la base de datos en uso en cualquier momento.

Hasta ahora hemos empleado la reutilización de DLL simple, con la funcionalidad, su archivo de configuración y las dependencias implementadas en todos los lugares donde se utiliza. Debido a que cualquier cambio ahora debe hacerse en varios lugares, este método es doloroso cuando se crean nuevas versiones de la funcionalidad o cuando nuevos clientes quieren usarla.

Nos preguntamos si hay una mejor manera de hacer esto, y hemos encontrado dos posibles alternativas.

1. Coloque la DLL (y las dependencias) en el GAC. La pregunta es cómo configurar el componente. Como los clientes no tienen interés en la configuración, nos inclinamos por almacenar el archivo de configuración en una ruta codificada en el servidor.

2. Publique la funcionalidad como un servicio interno (basado en REST). El acceso al mismo puede limitarse a clientes internos que usan el firewall.

Tal como lo vemos, las ventajas del # 1 parecen ser el rendimiento y posiblemente la seguridad, mientras que el # 2 puede verse como más simple de configurar.

¿Nos estamos perdiendo algo importante aquí? ¿Alguien ha estado en una situación similar antes y quiere compartir alguna idea?

Answer 1

Este es un problema con el que he luchado muchas veces y realmente no hay una mejor respuesta aparte de eso depende. Mi opinión personal es que debe mantenerse alejado de la opción 1 por un par de razones:

1. Al hacer que todos sus clientes compartan un solo binario, ahora requerirá que todos sus clientes sean probados cada vez que realice un cambio en él. Ahora sé que, en su caso exacto, es posible que tenga que hacer esto de todos modos, ya que podemos suponer que modificaría la base de datos que se encuentra detrás del componente.
2. No codifique nada. Puede almacenar su ruta de configuración en una sección AppSettings en el archivo machine.config.

En cuanto a la opción 2, una alternativa sería usar WCF (suponiendo que su entorno pueda soportarlo). Usando WCF, podría usar un transporte TCP usando la serilización binaria (y podría haber un transporte de memoria compartida). Ambos ayudarían a acercar la brecha de rendimiento (aunque la opción 1 siempre superará a un enfoque basado en el servicio).

Al ir a la opción 2, también alivia la necesidad de volver a probar a todos los clientes, ya que puede desarrollar pruebas automatizadas para validar que su contrato no se ha incumplido. Esto le permitirá publicar en un solo lugar, ejecutar pruebas automatizadas rápidas y saber que no está rompiendo los clientes.

Dicho esto, puede lograr lo mismo utilizando la opción 1 y un buen conjunto de pruebas unitarias, pero según mi experiencia, la opción 2 será más fácil a largo plazo.

La opción 2 también le permite ampliar el servicio en el futuro si alguna vez necesita más potencia de la CPU.

Personalmente, creo que la Opción 1 es más fácil de configurar, ya que no tendrá que ocuparse de configurar su firewall, manejar la autenticación, configurar un servicio, etc. También será más fácil de depurar (la distribución de una aplicación introduce nuevos tipos de fallas, por ejemplo, el sitio que aloja su servicio se bloquea y sus clientes comienzan a tener fallas).

Una última sugerencia es que utilice un patrón de proxy / fachada para aislar a sus clientes de la ubicación real del servicio. Esto le permitirá expandirse con el tiempo sin tener que modificar el código del cliente.

Answer 2

Como Josh ya dijo, desafortunadamente la respuesta para este tipo de preguntas es a menudo "depende".

Soy un gran admirador del GAC, pero solo debe poner un código del que esté seguro de que funciona (casi) perfectamente y que no necesita actualizarse muy a menudo. Mientras un fragmento de código esté "en desarrollo", simplemente publíquelo junto con todas las aplicaciones que lo usen.

Answer 3

Yo diría que usar la Opción 1 sería más simple y fácil, especialmente porque solo tendrá que pasar más tiempo limitando la disponibilidad de REST. (juego de palabras)

Answer 4

Josh señala WCF como una opción, y esa es seguramente la forma en que yo iría con esto.

¡Este problema es exactamente lo que SOA debe resolver!