wcf - servicios - soap vs rest

¿Por qué debería un desarrollador usar servicios web en lugar de conexiones directas a un db? (6)

Estoy buscando una lista de las "diez principales" razones por las que deberíamos estar conectando a bases de datos remotas a través del 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 perdiendo la discusión. Tengo una comprensión básica de WCF / servicios web, nadie más lo hace. Podemos hacer lo que queramos para seguir adelante, pero debemos seguir con lo que elijamos ahora.

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

Los servicios web de WCF pueden, si se configuran correctamente, ser más seguros.
Solo es necesario realizar cambios en el DB en el nivel de servicio (archivo de configuración o servicio de recompilación).
Una vez configurados y alojados, los servicios web son más fáciles de consumir.

Seguridad. No está otorgando acceso DB a nadie más que a un servidor web / usuario de la aplicación.
Esto es muy importante cuando tienes toneladas de usuarios. Evita el dolor del mantenimiento del usuario / rol en el lado de DB.
Reducción de carga DB El servicio web puede almacenar en caché los datos que recuperó de DB.
Capacidad para tolerancia a fallas: el servicio puede cambiar entre las fuentes de datos primarias / DR sin que los consumidores del servicio implementen detalles de la conmutación por error.
Escalabilidad: el servicio puede distribuir solicitudes entre varias fuentes de datos paralelas sin que los consumidores del servicio implementen detalles de la selección de recursos.
Encapsulación Puede cambiar la implementación subyacente de DB sin impactar a los usuarios del servicio.
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 es una carga importante en la base de datos y, a menudo, muy difícil de implementar dentro de un DB.
Puede o no aplicarse a usted: ciertas decisiones de arquitectura no son accesibles para DB. Por ejemplo, los servidores Java que se ejecutan en Unix tienen un acceso fácil a una base de datos, mientras que un cliente Java que se ejecuta en una PC con Windows no tiene conocimiento de la base de datos ni es posible que lo desee.
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 los datos en cada uno de ellos es más difícil (ya que debe tener en cuenta los problemas como las fallas antedichas / etc ...) que construir una capa de consumidor para un servicio web.
La optimización del rendimiento. Asumiendo que la alternativa es que los clientes ejecuten sus propias consultas (y no los procedimientos almacenados previamente), puede estar 100% seguro de que comenzarán a utilizar consultas que no sean ó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 exclusivos de los servicios web.

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

Para ser claro, algunos de estos problemas pueden no ser aplicables a TODAS las situaciones. Algunas personas no se preocupan por la portabilidad. Algunas personas no necesitan preocuparse por la seguridad de DB. Algunas personas no necesitan preocuparse por la escalabilidad de DB.

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

2) El servicio web admite la comunicación de diferentes plataformas (sistemas operativos como Windows, iOS, Android, etc.) de forma muy sencilla y efectiva. por ejemplo, considere una situación en la que la aplicación android y la aplicación ios quieren comunicarse con un sitio web que está basado en Java, de modo 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.

En general

El nivel de servicio web promueve la reutilización de solicitudes de datos comunes para múltiples aplicaciones
El servicio web se puede configurar con la administración de la versión que desvía muchos problemas que surgen del desarrollo del 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.
El servicio web ha evolucionado para permitir opciones flexibles para enviar solicitudes y obtener resultados de respuesta en un formato común como JSON utilizando un URI simple, lo que significa que las aplicaciones de cliente pueden desarrollarse utilizando un estándar más común que fomenta interfaces uniformes confiables.

Me acaban de ver con ASP.NET Web Api y tengo pensado hacer primero los servicios de datos.

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

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

Recientemente me encontré en una situación frustrante con una aplicación web de 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 para encontrar los archivos dll correctos para usar en base a conexiones de configuración web y nombres TNS.

Los intentos de conectarse a la base de datos fallaron con mensajes de error "ya no admitidos". Por curiosidad, descargué Oracle 12c e hice algunas conexiones a nivel de aplicación que funcionaban muy bien con mis nombres 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. Sin embargo, para mi decepción, se crearon con métodos que se asignaron específicamente a las tablas seleccionadas. 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 antiguos que estaba usando para abstraer la interfaz del cliente y las capas de lógica de negocios.

Así que lo primero que pensé fue que todas las solicitudes de datos comunes, como completar la lista desplegable o autocompletar con datos de toda la empresa, se realizan 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 que cada desarrollador tenga dificultades con la configuración y el ensamblaje de versión / carga, problemas de TNS?

asi que....

Para problemas de múltiples servidores de bases de datos, como usar procedimientos almacenados de Oracle en una aplicación .NET MVC que normalmente podría usar 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?
De nuevo, la interfaz con el cliente se puede hacer usando JavaScript, JQuery y JSON que ya está utilizando si está haciendo esto utilizando Web Api para realizar solicitudes de datos de SQL Server.

Soy un desarrollador / analista de aplicaciones y no un administrador de bases de datos, así que mi perspectiva es la experiencia de la constante frustración de tener que modificar constantemente las aplicaciones cuando las herramientas de bases de datos evolucionan.

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 hacerse a través de servicios web.

No hay ninguna razón por la que una conexión de base de datos no sea segura
Puede encapsular la base de datos en una capa de acceso a datos (posiblemente Entity Framework)
Los servicios web no son más fáciles de consumir que una capa de acceso a datos bien escrita.

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

Además, agrega una capa de protocolo de mensaje SOAP que agrega un golpe de rendimiento a las aplicaciones web que han sido ''coaccionadas'' para salir con este ''cerdo''. Estoy trabajando en un proyecto en este momento donde nuestra nueva aplicación MVC-4 ha sido instruida para usar dicho DAL. Tenemos la carga de tener que cambiar tanto la firma de WebMethod como la firma de SP cada vez que aparece una nueva historia de usuario que requiere dichos cambios; que para nosotros, es cada sprint. Inherente a este enfoque de paso a paso son dos niveles estrechamente unidos.

Los servicios web forman una API que define 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 administre independientemente de esas influencias externas.
Permitir el acceso solo por los servicios web garantiza que la lógica de la aplicación tenga la oportunidad de ejecutarse, protegiendo la integridad de los datos.
Los servicios web permiten que se tomen las medidas de autenticación / autorización más adecuadas, a diferencia de una base de datos que requiere privilegios de nombre de usuario y contraseña / nivel de tabla.
Los servicios web ofrecen la oportunidad de utilizar el descubrimiento y la configuración automáticos del servicio.
El tráfico de los servicios web se puede cifrar para el tránsito a través de redes no seguras. ¿No conoces ninguna solución directa de conexión DB que permita eso ...?

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