.net - interno - web config handlers error
Servicio web o DLL? (10)
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 un archivo DLL que encapsule la mayor parte de la funcionalidad necesaria y luego llamarlo a través de una interfaz de Web Forms para la ejecución manual y una aplicación de consola que se ejecuta 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 llamada por un recurso externo, creo que el esfuerzo extra requerido para implementar un servicio web podría 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 se vio involucrado en un accidente grave, me pidieron que me adelantara.
En este momento no hay 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.
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, sus aplicaciones internas utilizarán la funcionalidad expuesta por el componente que diseña.
En interés de la facilidad de mantenimiento, puede cargar este ensamblado desde una URL con bastante facilidad, y si este componente necesita ser envuelto en un servicio web, es posible y su código puede crear clases de proxy web con un mínimo de cambios de código.
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á ingresar al servicio web de sus clientes, deberá establecer puntos de interrupción en ambos lados de las llamadas.
El otro problema con los servicios web para usted es que necesita fracasos de manejo mucho más robustos. 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 mínima adaptación.
Personalmente, haría lo que dijiste; 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.
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, qué hará este dll. De lo contrario, solo estás escuchando las preferencias de los pueblos.
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 usar 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. Además, Spring tiene una integración del programador de Quartz, es posible que también desee estudiarlo.
Usar 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.
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 requisitos. 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
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 elección correcta es Servicio web. La razón es muy simple también.
1) Consistencia del modelo de dominio y lógica de negocios. 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 DB y control de concurrencia. Mucho más fácil de resolver en un dominio de aplicación.
En cuanto a los Cons sugeridos por otros, los considero 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, contras reales de mi parte:
1) Más complejo. 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) Requiere 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 gestió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 aplicaciones, lamento no haber golpeado al equipo de desarrollo lo suficiente como para ir con la ruta de los servicios web.
Entonces, ¿cuál fue tu decisión final? Han pasado cuatro años.
No puedo creer que la respuesta aceptada haya sido la que te aconsejó usar una DLL ...
"No imaginamos nada que cambie 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.