¿Servicio web o DLL?

Question

Estoy creando una aplicación a la que debe acceder tanto una interfaz web alojada en una red interna como también ejecutarla como una tarea programada. No será necesario acceder a nada fuera de nuestros sistemas internos y, una vez que la aplicación esté en funcionamiento, no imaginamos nada que cambie durante un tiempo.

Mi idea inicial es crear una DLL encapsulando la mayor parte de la funcionalidad necesaria y luego llamarla a través de una interfaz Web Forms para ejecución manual y una aplicación de consola ejecutándose como una tarea programada automática (diaria).

Otra sugerencia ha sido exponer un servicio web para la funcionalidad principal en su lugar, pero como la aplicación nunca necesitará ser invocada por un recurso externo, creo que el esfuerzo extra requerido para implementar un servicio web puede no valer la pena . La solución DLL también debería ser sustancialmente más rápida (?).

Mi pregunta es ¿qué ruta elegirías? ¿Hay algún pros/contra que no haya cubierto? ¿Alguna omisión evidente?

Descargo de responsabilidad: Soy nuevo en .Net pero debido a que uno de nuestros desarrolladores estuvo involucrado en un accidente grave, me pidieron que me adelantara.

Answer 1

Personalmente, digo ir con la DLL. Será rápido y simple.

Con un servicio web, tendrá que pensar en su red, firewalls, rendimiento, etc. También hace que sea más difícil de depurar ya que no podrá entrar en el servicio web de sus clientes, lo hará tiene que establecer puntos de interrupción en ambos lados de las llamadas.

El otro problema con los servicios web para usted es que necesita fallas de manejo mucho más robustas. Con una DLL, usted sabe que una llamada a un método tendrá éxito, pero con un servicio web, deberá estar preparado para que la llamada falle o caduque cada vez que realice una llamada.

Por último, si encuentra una necesidad de un servicio web en una fecha posterior, debería ser capaz de convertir con bastante facilidad la DLL en un servicio web con una modificación mínima.

Answer 2

Tienes razón, los servicios web son muy complicados por la experiencia y mucho más lentos. Sugiero - hacer un PONO (simple objeto .net antiguo), pero use interfaces. Mire en el marco de Spring.NET: puede exportar este objeto para usted como cualquier tipo de servicio (web), por lo que no necesita realizar plumming. En el lado del cliente, también puede usar el muelle para realizar la inyección de dependencia y decidir si desea la implementación del servicio web o la DLL en proceso, simplemente cambiando el valor en el archivo de configuración. También Spring tiene una integración del programador de Quartz, es posible que también desee examinarlo.

Answer 3

Personalmente, haría lo que usted dijo; poner mi lógica en la DLL. Luego use la DLL desde su aplicación, servicio web y la interfaz que aún no se haya determinado que soliciten en el futuro.

Answer 4

Ahora mismo hay no necesidad de crear un servicio web. Simplemente tendría que mantener otro servicio IIS en su servidor. Si más adelante crea una interfaz que necesitará esa DLL, simplemente puede consultarla. Entonces no hay necesidad de hacerlo de manera preventiva.

Answer 5

El uso de DLL es una forma correcta, es más rápido y proporciona libertad en el futuro para crear un servicio web con el uso de estos dlls (si es necesario) con más seguridad sobre el servicio web.

Answer 6

Realmente necesitamos más información. Es difícil responder sin saber exactamente cuáles son sus requisitos.El enfoque en capas (dll/clase separada) es simple y rápido. Un enfoque escalonado (servicio web) le permitirá tener un entorno y le dará más abstracción. Puede cambiar el código detrás del servicio web sin cambiar sus clientes.

Pero para evaluar esto necesitaríamos saber cuál es su proyecto. De lo contrario, solo estás escuchando las preferencias de los pueblos.

Answer 7

Encapsular su lógica en un Ensamblaje sería suficiente para su solución, ya que parece que nada saldrá de los límites de su dominio, ambas aplicaciones internas utilizarán la funcionalidad expuesta por el componente que diseña.

En aras de la facilidad de mantenimiento, puede cargar este ensamblado desde una URL con bastante facilidad, y en el futuro si este componente necesita ser incluido en un servicio web, es posible y su código puede crear clases de proxy web con cambios mínimos de código

Answer 8

estoy desarrollando una aplicación similar. el enfoque que he adoptado es tener mi lógica de extracción en dll's. esto está expuesto a través de un servicio web. Encuentro que los servicios web son más simples ya que no necesito delegar interfaces o exponer mis objetos (uso las clases para encapsular datos) en el cliente. Luego, los desarrolladores web y los desarrolladores de winforms escriben su propia capa de presentación. si bien hay pros y contras (no entraré en ellos), los servicios web son más simples ya que tengo una sola capa. usando la comunicación remota, necesito la interfaz adicional o la biblioteca del lado del cliente que debe instalarse en cada cliente. De esta forma, administro solo el lado del servidor mientras que las diferentes GUI son independientes. Solo me gusta la codificación acoplada. ejecutamos numerosos servicios de Windows que también usan los servicios web. la nuestra es una organización de tarjeta de crédito e interactuamos con numerosos sistemas. los servicios web dan el uso de la mayor flexibilidad.

después de todo eso, se reduce a su preferencia personal teniendo en cuenta sus necesidades. Diría, no elijas 1 sobre otro sin considerar la capacidad de hacer cambios con el mínimo esfuerzo. He encontrado rad aplicaciones para cambiar rápidamente con nuevos requisitos continuamente añadidos. tómese su tiempo, acondicione el alcance y la duración de su proyecto y las necesidades. luego desarrolla tus fortalezas

Answer 9

Wow wow wow. ¿Todos comparten una base de datos? Si ese es el caso, no, no y no. Si la base de datos no se comparte, entonces definitivamente es DLL.

La opción correcta es Servicio web. La razón es muy simple también.

1) Consistencia del modelo de dominio y lógica comercial. Supongamos que almacena una enumeración en una columna y agrega una enumeración e implementación en una aplicación. Ahora romperá las otras dos aplicaciones.

2) Facilidad de implementación. Un cambio = una implementación. Si es un archivo DLL, un cambio = 3 implementación.

3) transacciones de base de datos y control de concurrencia. Mucho más fácil de resolver en un dominio de aplicación.

En cuanto a los contras sugeridos por otros, me parecen demasiado parciales.

1) Dificultad en la depuración en el dominio de la aplicación. Debe publicar las posibles excepciones a través de WSDL como excepciones de error. El cliente que realiza la llamada también debe manejar esas excepciones de fallas apropiadamente. También es increíblemente fácil configurar pruebas unitarias y simulacros tanto para el cliente como para el servidor. Breakpoint no es la forma correcta de depurar y trabajar con aplicaciones distribuidas. Puedes, y no es difícil. Simplemente no creo que ese sea el enfoque correcto.

2) Rendimiento. WCF le permite establecer diferentes enlaces a través de la configuración.Desde http básico (que es más fácil de depurar) hasta llegar a named pipe, que puede usar para obtener un rendimiento de llamada casi nativo. Esta decisión puede (casi. Hay algunas peculiaridades con diferentes enlaces que debe tener en cuenta.) Decida también después del desarrollo.

3) Seguridad. Decir que WCF no maneja la seguridad es hilarantemente incorrecto.

Por último, los contras reales de mí:

1) más complejas. Convenido. Un contexto diferente hace que el diseño de la aplicación sea más difícil. Eso va de dos maneras, aunque. Esta complejidad impone una clara separación de niveles. El contexto de la presentación debe mantenerse donde están, a nivel de presentación.

2) Requieren más planificación. El diseño de contratos para los servicios web de WCF es un arte en sí mismo.

3) Gastos generales de administración para la configuración. Puede ser desalentador para los desarrolladores más nuevos, pero espero que pueda superar este obstáculo rápidamente. La configuración WCF es una espada de doble filo, potente, pero compleja (para algunos).

Mi experiencia personal es que cada vez que se comparte una base de datos y se usa la DLL en varios dominios de aplicación, lamento no haber golpeado al equipo de desarrollo lo suficiente como para ir con la ruta de servicios web.

¿Cuál fue su decisión final? Han pasado cuatro años.

Answer 10

No puedo creer que la respuesta aceptada era la que más le aconsejó utilizar una DLL ...

"No prevemos que nada vaya a cambiar por algún tiempo."

Es por eso que tenemos que dedicar tiempo a solucionar los problemas creados por los desarrolladores que toman estas decisiones. No pienses solo de hoy, piensa en el mañana. Las cosas de la base de datos deben ocultarse desde el cliente, ¿qué sucede si tiene que agregar un nuevo cliente y mañana uno nuevo? Construya contratos apropiados y use servicios, web o no.