Capa de acceso a datos como servicio web: ¿es una buena idea?

Question

He estado investigando por un tiempo y he creado un prototipo de servicio web ASP.NET como DAL para algunos sitios web ASP.NET 2.0. Solo me gustaría pedir algunas ideas/consejos de desarrolladores más experimentados que hayan implementado exitosamente DAL como servicio web. ¿Cuáles son los inconvenientes/riesgos para implementar DAL como un servicio web? ¿Cuál es la mejor forma de proteger o autenticar el consumo de este servicio web? WCF está fuera de cuestión, estaré codificando en VS 2005.

Gracias.

Answer 1

Creo que la mayor desventaja de este enfoque es la sobrecarga adicional de llamar al servicio web. Si necesita frecuentes consultas/actualizaciones para DAL, esto puede ser bastante lento.

Mi opinión es que ese enfoque es una especie de sobreingeniería, a menos que realmente necesite tener DAL físicamente separado para diferentes consumidores y necesita alguna validación/procesamiento adicional en DAL (que de todos modos es algo incorrecto).

Asegurar puede ser bastante simple. Puede usar SSL junto con la autenticación IIS para su interfaz de servicio público.

Por lo tanto, esas son mis $ 0,03

Answer 2

El único verdadero desafío que he enfrentado con la exposición de datos a través de un servicio web basado en ASMX estaba soñando con todos los métodos necesarios para obtener datos de forma eficiente. A veces es difícil tener la disciplina para respetar el nivel entre la aplicación y la base de datos.

Si se está implementando en un entorno de Intranet con AD, la Autenticación de Windows integrada es una forma excelente de controlar quién puede y quién no puede interactuar con un servicio. Es útil agrupar las clases de servicio según las funciones del consumidor, de modo que permissions can be controlled declaratively in the Web.config. Tiendo a mantener los métodos de lectura en una clase de servicio diferente que inserte métodos de actualización y eliminación

Evite las llamadas al servicio de conversación. Por supuesto, es conveniente evitar las llamadas de la base de datos de conversación en un sistema de dos niveles, pero pagarás al hablador por las llamadas habladas cuando aumente la cantidad de niveles. Elige enviar objetos más grandes. Por ejemplo, si tiene una tabla con algunas búsquedas, el envío de un objeto a través del cable con valores pre-consultados a menudo le ahorrará una segunda o tercera llamada, y no debería causar una carga excesiva en el sistema.

Espero que estas ideas ayuden.

Answer 3

Recomendaría esto hasta que pueda pasar a WCF. De lo contrario, pasará todos sus datos de ida y vuelta en XML basado en texto a través de HTTP, lo que ralentizará considerablemente las cosas. También tendrá muy pocas opciones sobre seguridad, estando limitado a SSL para el cifrado.

WCF le permitirá enviar datos binarios a través de TCP/IP, canalizaciones con nombre o colas de mensajes, y le permitirá una gran flexibilidad en términos de seguridad. mirada

Answer 4

Vamos a esto desde el punto de vista de la evolución de los proyectos de desarrollo de software "Enterprise":

1. Comience con una aplicación muy sencilla y bien organizada, y tal vez nuevo con problemas de mantenimiento pequeños (si' afortunado). Los programadores pueden ser graduados recientes, pero el sistema es joven o lo suficientemente limpio como para que puedan ser muy ágiles y responder rápidamente a las solicitudes de cambio. La mayoría del código de la base de datos está en procedimientos almacenados. No hay DBA involucrado.
2. La aplicación crece y hay una necesidad de que varios programadores trabajen en la aplicación al mismo tiempo.Los nuevos graduados descubren el control de fuente para ayudarlos a compartir el código entre múltiples programadores y alejarse de los procedimientos almacenados a favor del diseño n-Tier o un ORM para facilitar la versión del código de la base de datos. Esto funciona bien siempre que cada aplicación individual esté bastante aislada. Un DBA ahora puede comenzar a ayudar a ajustar las consultas.
3. Esto eventualmente evoluciona en un sistema interconectado de aplicaciones que ha crecido orgánicamente más que por diseño. Las solicitudes de cambio se vuelven difíciles, ya que los cambios en un área tienen efectos sutiles en otros. Para resolver este problema de múltiples aplicaciones que hablan a la misma base de datos y que necesitan compartir lógica empresarial común y compleja, los programadores recurren a una arquitectura orientada a servicios (servicios web). Los datos antiguos y los niveles comerciales se analizan, combinan y refactorizan en un conjunto común de servicios web. La mayoría de los programadores ahora ya no saben cómo conectarse a su base de datos, solo aquellos que trabajan en los servicios básicos pueden hacer esto, e incluso deben dejar cualquier sql real al DBA. Si las pruebas unitarias no están en uso, ahora se descubre como parte de la configuración de un sistema de integración continua.
4. El sistema continúa creciendo, pero el negocio crece aún más rápido. Todo funciona; la calidad es buena y el rendimiento no es bueno, pero aún así es aceptable. El problema es que las tasas de cambio son demasiado lentas. Las capas de proceso entre los programadores y el código les impiden mantenerse al día con el negocio de una manera rentable. Alguien descubre métodos ágiles.
5. Regrese al paso uno.

tomar en serio una vez más, poniéndolo en este contexto vemos que los servicios web realmente abarcan tanto la capa de datos y la capa de negocio. El objetivo de una capa de servicio es hacer que se comparta un conjunto común de reglas entre varias aplicaciones. Dejar la capa empresarial fuera de su servicio les da a los programadores la oportunidad de escribir su propio código comercial para cada aplicación, y eso es realmente contraproducente para el propósito de usar servicios en primer lugar.