Pregunta

No estoy convencido: creo que podría ser útil exponer sus datos a diferentes consumidores que pueden crear sus aplicaciones front-end sobre su servicio web.

¿Puede alguien proporcionar muestras de cuando usar servicios web para envolver la capa de acceso a datos es una mala idea?

¿Fue útil?

Solución

Dependiendo de lo que defina como una 'capa de acceso a datos', puede haber o no una buena razón para hacerlo. Tradicionalmente, las API distribuidas, como los servicios web o las capas RPC, viven en la siguiente capa hacia arriba. Esto tiene las siguientes ventajas:

  1. Sin el acoplamiento estrecho a la base de datos Puede ajustar esta capa para que funcione bien con acceso distribuido, por ejemplo, organizando la API para minimizar los viajes de ida y vuelta.

  2. Puede poner una capa adicional de validación en la API. Una capa de acceso a datos sin procesar puede permitir que se escriban datos incorrectos en el sistema. Por esta razón, sería malo exponerlo a clientes no confiables.

  3. Puede colocar seguridad a nivel de aplicación sobre la capa de servicios de una manera que podría no ser posible para una capa de acceso a datos.

  4. Los puntos 1 y 2 significan que puede reutilizar las validaciones de las reglas de negocio en el nivel medio.

La exposición de una API simple para operaciones CRUD también se puede lograr conectándose directamente al servidor de la base de datos, por lo que una capa de servicio web además de esto no le dará nada que el DBMS no proporcione. Algunos motores de base de datos también pueden atender consultas directamente a través de HTTP para que pueda hacer un túnel a través de la mayoría de los firewalls. Sin embargo, los aspectos de seguridad de esto significan que es casi seguro que no desea exponer esto a la Internet pública.

Si bien, en teoría, podría exponer las operaciones CRUD (que es lo que supongo que quiere decir con 'capa de acceso a datos') a través de un servicio web, existen algunas razones bastante buenas para no hacerlo y relativamente pocos beneficios para hacerlo. .

Otros consejos

El mayor impulso en el mundo de hoy es hacia la computación en la nube o SaaS.

Con eso en mente, muchas aplicaciones importantes, incluidas SalesForce (CRM), Google, Parature (servicio de asistencia), etc., exponen sus aplicaciones a través de servicios web.

No es solo una buena idea, es la única forma de hacer que su aplicación sea tomada en serio por las empresas que buscan integrarla en su entorno.

Dicho esto, el único ejemplo en el que puedo pensar cuando utilizo servicios web para envolver su DAL es una mala idea cuando solo una aplicación llamará al DAL y está bajo su control de desarrollo directo. Esto se debe a la penalización de rendimiento pagada por serializar / deserializar los datos a través de un límite de servicio web.

Bueno, si está exponiendo toda su API a través de un servicio web sin seguridad, puede ser una mala idea.

Pero si está exponiendo las partes requeridas, de una manera segura y de solo lectura, y a sus clientes les gusta, eso seguramente será algo bueno.

Si alguna vez necesita persuadir a la gerencia, recuerde que "Google lo hace".

En .NET, WCF parece ofrecer una forma de evitar el éxito de rendimiento que Chris menciona. WCF debería permitirle que su componente de acceso a datos se ejecute en proceso para su propia aplicación, pero que también se exponga fácilmente como un servicio web. (Descargo de responsabilidad: en realidad no he implementado esto, solo lo miré).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top