studio - web service json c#

Mejores prácticas: acceso directo a SQL vs. servicio web (5)

Con respecto a una aplicación que tiene una versión de cliente web y de escritorio:

¿Cuál es la mejor práctica para el cliente de escritorio que necesita acceso a un servidor SQL?
¿Cuáles son los beneficios de conectarse a la base de datos desde la aplicación en comparación con el uso de un servicio web?
¿Cuál proporciona mayor seguridad?
Qué tipo de ámbito requeriría uno frente a otro (intranet empresarial frente a aplicación web, etc.)
¿Hay otras consideraciones que son necesarias al elegir en la plataforma?

¿Cuál es la mejor práctica para el cliente de escritorio que necesita acceso a un servidor SQL?

Si está utilizando un servidor SQL local, acceda directamente a la base de datos. Si el cliente tiene que usar una base de datos SQL en otro sistema, se prefiere el uso de un servicio web para obtener una protección adicional y la ventaja adicional de tener una capa empresarial que debería poder manejar múltiples usuarios.

¿Cuáles son los beneficios de conectarse a la base de datos desde la aplicación en comparación con el uso de un servicio web?

La conexión a través de un servicio web siempre será un poco más lenta y las modificaciones a la base de datos serán un poco más difíciles de agregar a todo el sistema. (Básicamente, eso significaría que necesita crear una versión más nueva del servicio web a la vez que mantiene el servicio web anterior para la compatibilidad con versiones anteriores).

¿Cuál proporciona mayor seguridad?

El uso de servicios web tiende a ser más seguro, aunque la seguridad es a menudo más un problema de personas que de software. Pero con el servicio web entre el usuario y la base de datos, la conexión a la base de datos es más segura ya que el usuario no puede acceder directamente a ella. (Excepto por la funcionalidad que proporciona a través del servicio web). Este punto es discutible cuando el cliente y la base de datos están en el mismo sistema porque el usuario puede obtener acceso completo.

Qué tipo de ámbito requeriría uno frente a otro (intranet empresarial frente a aplicación web, etc.)

Los servicios web son mejores para las aplicaciones cliente-servidor, donde los usuarios no deben tener acceso directo a la base de datos. De lo contrario, una conexión de base de datos directa solo mejoraría el rendimiento. Al crear un servicio web, comience escribiendo una biblioteca genérica (clase) que proporcionará la funcionalidad para el servicio web. Cree un servicio web alrededor de esta biblioteca (comercial), exponiendo los métodos importantes al mundo exterior. Cualquier sitio web puede llamar a esta biblioteca directamente sin utilizar el servicio web, aunque siempre puede optar por permitir que el código del sitio web acceda a los datos a través del servicio web. Incluso si creas solo una aplicación de escritorio con una base de datos local, escribir una biblioteca empresarial con lógica para acceder a la base de datos es algo muy bueno. Su cliente podría llamar a esta biblioteca de negocios directamente oa través de un servicio web, según sus necesidades.

¿Hay otras consideraciones que son necesarias al elegir en la plataforma?

Principalmente solo la cantidad de hardware que estás dispuesto a usar para configurar las cosas. Si puede darse el lujo de configurar un servidor de base de datos, un servicio web independiente para los servicios y un tercero para su sitio web, con una docena de sistemas cliente, puede optar por la versión con más niveles, donde el cliente y el sitio web llamar al servicio web, que llama a la base de datos. Pero si todo tiene que ejecutarse en un solo sistema, entonces en lugar de eso, apéguese a la aplicación y la capa / biblioteca empresarial.

Sin embargo, agregar capas reducirá el rendimiento de la vista de un solo usuario. Sin embargo, trabajar con varias capas puede mejorar el rendimiento general porque los recursos se dividen mejor entre varios usuarios.

Dado el contexto, puede haber una gran preocupación de seguridad con el acceso del cliente a las bases de datos. Requiere que los usuarios accedan a la base de datos o que creen una cuenta de servicio. Dar a los usuarios acceso directo a la db plantea riesgos. Ambos enfoques abren la puerta para explotar las dll de escritorio para conectarse a db fuera del contexto de la aplicación (varias veces he visto casos en los que existe una clase de acceso a datos común que utilizan todas las operaciones funcionales. Y, por supuesto, estos componentes inicializan toda la información de conexión . El acceso basado en la reflexión hace que sea fácil acceder a métodos protegidos o privados, a menos que usted ejerza privilegios de seguridad).

Los servicios web exponen operaciones funcionales que no exponen ninguna operación basada en SQL. Esto no solo es más seguro, sino que también aleja a su cliente de su implementación de almacenamiento de datos.

Una vez más, depende de su contexto. Sin embargo, en el ámbito de la empresa / ISV, generalmente es un gran no-no.

La regla general es la siguiente:

Escriba un conjunto de acceso a datos independiente que se comunique con la base de datos.
Si está buscando interoperabilidad entre diferentes plataformas / clientes, exponga este conjunto como un servicio web SOAP.
Si está buscando rendimiento, use el ensamblaje directamente en las aplicaciones .NET de su cliente.

Lo mantendría simple y minimizaría la cantidad de capas. Las capas cuestan el rendimiento, introducen complejidad y requieren cambios en más ubicaciones.

Por lo tanto, si la conexión de red entre la aplicación y el servidor Sql está abierta (por lo general, el puerto 1433 de TCP), usaría la conectividad Sql.

Si puede acceder a la base de datos desde el escritorio, debe hacerlo.

Tienes múltiples tipos de clientes. Eso significa que su aplicación debe tener múltiples capas. No significa que necesites múltiples niveles.

Pueden ser necesarios múltiples niveles si sus capas deben transferir datos a través de firewalls o si tiene diversas tecnologías.