¿Por qué un desarrollador debería utilizar servicios web en lugar de conexiones directas a una base de datos? [cerrado]

93

Estoy buscando una lista de las "diez principales" razones por las que deberíamos conectarnos a bases de datos remotas a través de un servicio web en lugar de conectarnos directamente a la base de datos. Este es un debate interno en este momento y estoy a favor del servicio web, pero estoy perdiendo la discusión. Tengo un conocimiento básico de WCF / servicios web, nadie más lo tiene. Podemos hacer lo que queramos para seguir adelante, pero debemos ceñirnos a lo que elijamos ahora.

Esto es lo que se me ocurrió. ¿Nunca más?

  1. Los servicios web WCF pueden, si se configuran correctamente, ser más seguros.
  2. Los cambios en la base de datos solo deben realizarse en el nivel de servicio (archivo de configuración o servicio de recompilación).
  3. Una vez configurados y alojados, los servicios web son más fáciles de consumir.
wcf web-services DenaliHardtail
fuente

Respuestas:

120

  1. Seguridad. No está otorgando acceso a la base de datos a nadie más que al servidor web / usuario de la aplicación.

    Esto es muy importante cuando tienes muchos usuarios. Evita el dolor del mantenimiento de roles / usuarios en el lado de la base de datos.

  2. Reducción de carga DB. El servicio web puede almacenar en caché los datos que recuperó de la base de datos.

  3. Agrupación de conexiones de base de datos (hat / tip @Dogs).

    Un servicio web puede utilizar un pequeño grupo de conexiones de base de datos abiertas permanentemente. La ayuda de diversas formas:

    • El grupo de conexiones de base de datos está limitado en el lado del servidor de la base de datos.

    • abrir una nueva conexión a la base de datos es MUY costoso (especialmente para el servidor de la base de datos).

  4. Capacidad de tolerancia a fallas: el servicio puede cambiar entre fuentes de datos primarias / DR sin que los consumidores del servicio implementen los detalles de la conmutación por error.

  5. Escalabilidad: el servicio puede distribuir solicitudes entre varias fuentes de datos paralelas sin que los consumidores del servicio implementen los detalles de la selección de recursos.

  6. Encapsulamiento. Puede cambiar la implementación de la base de datos subyacente sin afectar a los usuarios del servicio.

  7. Enriquecimiento de datos (esto incluye cualquier cosa, desde la personalización del cliente hasta la localización y la internalización). Básicamente, cualquiera de estos puede ser útil, pero cualquiera de ellos representa una carga importante en la base de datos y, a menudo, es muy difícil de implementar dentro de una base de datos.

  8. Puede que se aplique a usted o no: ciertas decisiones de arquitectura no son fáciles de acceder a DB. Por ejemplo, los servidores Java que se ejecutan en Unix tienen un fácil acceso a una base de datos, mientras que un cliente java que se ejecuta en una PC con Windows no es consciente de la base de datos ni es posible que usted desee que lo sea.

  9. Portabilidad. Es posible que sus clientes no estén todos en la misma plataforma / arquitectura / idioma. Volver a crear una buena capa de acceso a datos en cada una de ellas es más difícil (ya que debe tener en cuenta cuestiones como las conmutaciones por error mencionadas anteriormente, etc.) que crear una capa de consumidor para un servicio web.

  10. La optimización del rendimiento. Suponiendo que la alternativa es que los clientes ejecuten sus propias consultas (y no procedimientos almacenados predefinidos), puede estar 100% seguro de que comenzarán a utilizar consultas menos que óptimas. Además, si el servicio web limita el conjunto de consultas permitidas, puede ayudar significativamente a ajustar la base de datos. Debo agregar que esta lógica es igualmente aplicable a los procedimientos almacenados, no exclusiva de los servicios web.

También se puede encontrar una buena lista en esta página: 'Encapsular el acceso a la base de datos: una "mejor" práctica ágil'

Para ser más claros, algunos de estos problemas pueden no ser aplicables a TODAS las situaciones. A algunas personas no les importa la portabilidad. Algunas personas no necesitan preocuparse por la seguridad de la base de datos. Algunas personas no necesitan preocuparse por la escalabilidad de la base de datos.

DVK
fuente
26
Lo siento, no estoy de acuerdo. 1. Por lo tanto, otorga acceso a la base de datos a un grupo en lugar de a un único principal, sin diferencia. 2. Cualquier aplicación puede almacenar datos en caché. En cualquier caso, el tipo de datos que se pueden almacenar en caché entre varios usuarios serán datos de bajo volumen. 3. En cualquier caso, FT debe ser manejado por la base de datos. 4. Esta no es una función lista para usar y debe programarse. 5. Su capa de acceso a datos debería estar encapsulando. 6. Lo mismo. 7. ¿De verdad? ¿JDBC no se ejecuta en un cliente? 8. Buen punto, cuando importa, lo cual es raro. 9. consulta vs. SP no era parte de la pregunta.
John Saunders
7
1. Intente administrar eso en 5000 usuarios con cientos de roles. Ya no escala tan bien. 2. Depende completamente de una aplicación. Nuestro caso actual tiene una instancia de almacenamiento en caché de los resultados de una consulta que, en un caso súper optimizado, tarda 20 minutos en ejecutarse y que necesitamos ejecutar cientos de veces al día al menos desde diferentes aplicaciones. 3. FT se maneja en varios niveles. ¿Qué quiere decir "debería ser manejado por una base de datos"?
DVK
4
4. Por supuesto que hay que programarlo. Pero se puede programar en el servicio una vez, o en un trillón de aplicaciones cliente en varias plataformas con distintas capacidades. Hay una gran diferencia. No importa los problemas de la gestión de la configuración para el equilibrio de carga. 5. Mismo razonamiento. No es necesario volver a implementar DAL. De hecho, puede pensar en el servicio web como un DAL portátil para tranquilizar su mente. 7. No queremos que todos los clientes abran conexiones DB. ¿Es tan importante pedir? Nuevamente, estás olvidando los puntos 1-5.
DVK
2
8.> La arquitectura de 1 cliente ocurre MUY a menudo. De hecho, nunca trabajé en un proyecto sin tal situación en mi vida, pero estoy centrado en el mundo financiero. 9. No lo fue. Básicamente estaba jugando al abogado del diablo.
DVK
2
Me gusta esta respuesta, pero creo que se saltó uno de los puntos más importantes: la agrupación de conexiones. Si tiene 1,000,000 de clientes, tendrá 1,000,000 de conexiones abiertas o millones de conexiones que se abren y cierran constantemente. La intuición básica sobre la organización informática nos dice que un grupo bien ajustado de un par de cientos de conexiones de larga duración es astronómicamente más eficiente que tener un millón de conexiones de larga duración o millones de conexiones de corta duración. El HikariCP documenta un gran trabajo al desarrollar esta idea: github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
Dogs
15

En mi opinión, no debería exponer automáticamente su base de datos como un servicio web. Si resulta que necesita un servicio para exponer sus datos, escriba uno, pero no todo el acceso a la base de datos debe realizarse a través de servicios web.

  1. No hay ninguna razón por la que una conexión a una base de datos no deba ser segura
  2. Puede encapsular la base de datos en una capa de acceso a datos (posiblemente Entity Framework)
  3. Los servicios web no son más fáciles de consumir que una capa de acceso a datos bien escrita.
John Saunders
fuente
¿Por qué necesariamente XML? También hay mucho más ligero para analizar JSON, CSV para datos planos simples, etc ...
DVK
No es "sin una buena razón". Como se indicó anteriormente, dependiendo de sus requisitos y deseos de desarrollo futuro, podría ser necesario para su proyecto.
Chris Stewart
Escribo mi WS para consumir un DAL. ¿En qué puerto sugeriría exponer un DAL?
samis
@samus, no importa.
John Saunders
"No hay ninguna razón por la que una conexión a una base de datos no deba ser segura", bueno, es difícil, por ejemplo, asegurar la conexión entre un cliente de Windows y una base de datos. ¡Realmente difícil de implementar una conexión segura!
NoChance
12
  • Los servicios web forman una API, definiendo las interacciones permitidas entre los sistemas externos y los datos de la aplicación.
  • Los servicios web desacoplan la base de datos de las interacciones externas y permiten que la capa de datos se gestione independientemente de las influencias externas.
  • Permitir el acceso solo a los servicios web asegura que la lógica de la aplicación tenga la oportunidad de ejecutarse, protegiendo la integridad de los datos.
  • Los servicios web permiten tomar las medidas de autenticación / autorización más adecuadas, a diferencia de una base de datos que requiere un nombre de usuario y privilegios de nivel de contraseña / tabla.
  • Los servicios web brindan la oportunidad de utilizar el descubrimiento y la configuración automáticos de servicios.
  • El tráfico de los servicios web se puede cifrar para su tránsito a través de redes no seguras. ¿No conoce ninguna solución de conexión de base de datos directa que permita eso ...?

La mayoría de estos puntos se refieren a cualquier API formal, no específicamente a los servicios web.

brabster
fuente
1
Sí, eso era lo que iba a decir, si tiene una sola aplicación que accede a una base de datos, todos sus puntos también están disponibles para las API normales.
Ignacio Soler García
"Los servicios web forman una API, que define las interacciones permitidas entre los sistemas externos y los datos de la aplicación". También puede hacerlo con una base de datos.
Zapato
"Permitir el acceso solo a los servicios web garantiza que la lógica de la aplicación tenga la oportunidad de ejecutarse, protegiendo la integridad de los datos". - Yo diría que la integridad de los datos debería ser solo parte del DBMS.
Zapato
@Shoe Es bueno hacer cumplir la mayor integridad posible por parte de la base de datos, pero a medida que los datos comienzan a poblar y exponer deficiencias, como la necesidad de una validación de entrada, es bueno hacer cumplir esto en el nivel de la aplicación (aunque, por mi parte, prefiero hacer cumplir en el del lado del cliente, a veces debe tratarse en el lado del servidor si las reglas de validación dependen de los datos que solo el servidor conoce (guardados de la aplicación del cliente)). ¿Es importante cambiar el conjunto de reglas de integridad de una base de datos, me imagino que no es un asunto trivial?
samis
2

Escribir un servicio web que simplemente envuelva llamadas a procedimientos almacenados parece ser un enfoque equivocado para diseñar un buen DAL. Lo más probable es que sus procedimientos almacenados sean código heredado que quedó de un sistema cliente-servidor más antiguo, es decir, las reglas comerciales están enterradas en los SP. Si ese es el caso, lo que realmente está intentando es crear un bolso de seda de la oreja de una cerda.

Además, está agregando una capa de protocolo de mensaje SOAP que agrega un impacto de rendimiento a las aplicaciones web que han sido 'forzadas' a salir con este 'cerdo'. Estoy trabajando en un proyecto en este momento en el que se ha indicado a nuestra nueva aplicación MVC-4 que use dicho DAL. Tenemos la carga de tener que cambiar tanto la firma WebMethod como la firma SP cada vez que aparece una nueva historia de usuario que requiere tales cambios; que para nosotros, es cada sprint. Inherente a este enfoque de paso a través hay dos niveles estrechamente acoplados.

Sevasanakid
fuente
1
La API web abordó el problema de hinchazón de WCF / SOAP. Ahora es como un felino ligero, en forma y ágil; justo lo que necesita para servir con DESCANSO.
samis
En teoría, no es incorrecto llamar a procesos almacenados utilizando servicios web.
NoChance
2

1) El dolor de cabeza de mantener la base de datos se reduce desde el lado de los desarrolladores para que puedan concentrarse solo en el desarrollo.

2) El servicio web admite la comunicación de diferentes plataformas (sistemas operativos como Windows, iOS, Android, etc.) de una manera muy fácil y eficaz. por ejemplo, considere una situación en la que la aplicación de Android y la aplicación de iOS quieren comunicarse con un sitio web que está basado en Java, por lo que para la comunicación de las tres cosas, el servicio web es la mejor solución en lugar de mantener tres bases de datos diferentes.

Rohan
fuente
1

En general

  1. El nivel de servicio web promueve la reutilización de solicitudes de datos comunes para múltiples aplicaciones
  2. El servicio web se puede configurar con la gestión de versiones, lo que evita muchos problemas que surgen del desarrollo a nivel de la aplicación. Por ejemplo, si soy nuevo en un proyecto, ¿qué aplicación existente utilizo como un buen modelo para configurar mi aplicación para usar fuentes de bases de datos existentes?
  3. Web Service ha evolucionado para permitir opciones flexibles para enviar solicitudes y obtener resultados de respuesta en un formato común como JSON mediante el uso de un URI simple, lo que significa que las aplicaciones cliente se pueden desarrollar utilizando un estándar más común que fomenta interfaces uniformes confiables.

Acabo de empezar a usar ASP.NET Web Api y planeo hacer servicios de datos primero.

Recientemente me he centrado en aplicaciones web .NET MVC con el uso del marco de entidad.

  1. Si ya usa MVC, Web Api también usa MVC con el controlador Api, por lo que la curva de aprendizaje para construir los servicios es bastante sencilla.

Hace poco me encontré en una situación frustrante con una aplicación web MVC que estaba construyendo originalmente basada en procedimientos almacenados de Oracle. La versión original como Oracle 9 o incluso anterior, que presentaba otro problema con Visual Studio 2012, impulsaba un enfoque de fábrica de conexiones más moderno con ensamblajes de tiempo de carga que encontraban los archivos dll correctos para usar en función de las conexiones de configuración web y los nombres de TNS.

Los intentos de conectarse a la base de datos fallaron con mensajes de error "ya no es compatible". Por curiosidad, descargué Oracle 12c e hice algunas conexiones a nivel de aplicación que funcionaron muy bien con mis nombres de TNS y la dll de ensamblaje de carga y pude trabajar con Oracle sin problemas.

Se crearon algunos servicios web que funcionaban con conexiones a la versión anterior de Oracle. Fueron construidos con métodos que se asignaron específicamente a tablas seleccionadas, sin embargo, para mi decepción. Tendría que escribir el mío.

Me dijeron que el grupo que era responsable de mantener las bases de datos de Oracle estaría escribiendo nuevos procedimientos almacenados para reemplazar los más antiguos que yo estaba usando para abstraer la interfaz del cliente y las capas de lógica empresarial.

Entonces, mis primeros pensamientos fueron que todas las solicitudes de datos comunes, como completar la lista desplegable o autocompletar con datos de toda la empresa, se realizarían a través de servicios de datos que llamarían a los procedimientos almacenados de Oracle. ¿Por qué repetir ese proceso en cada aplicación y hacer que cada desarrollador tenga problemas con la configuración y el ensamblaje de versión / carga, problemas de TNS?

entonces....

  1. Para múltiples problemas del servidor de bases de datos, como el uso de procedimientos almacenados de Oracle en una aplicación .NET MVC que normalmente podría estar usando EF para el uso de datos de SQL Server, ¿por qué no llevar esos dolores de cabeza a los métodos de servicio Web Api donde esos problemas de configuración pueden aislarse?
  2. Nuevamente, la interfaz del cliente se puede hacer usando JavaScript, JQuery y JSON que ya está usando si lo está haciendo usando Web Api para realizar solicitudes de datos de SQL Server.

Soy un desarrollador / analista de aplicaciones y no un DBA, por lo que mi perspectiva es la de la experiencia con la frustración interminable de tener que modificar constantemente las aplicaciones cuando las herramientas de la base de datos evolucionan.

Brian Quinn
fuente