2009-07-06 13 views
17

Con respecto a una aplicación que tiene tanto una web y cliente de escritorio Versión:Mejor Práctica: SQL Acceso Directo vs servicio web

  1. ¿Cuál es la mejor práctica para el cliente de escritorio que necesita acceso a una ¿Servidor SQL?
  2. ¿Cuáles son los beneficios de conectarse a la base de datos desde la aplicación frente a usar un servicio web?
  3. ¿Cuál proporciona una mejor seguridad?
  4. Qué tipo de alcance necesitaría uno frente a otro (intranet empresarial vs. aplicación web, etc.)
  5. ¿Hay alguna otra consideración que sea necesaria al elegir en la plataforma?

Respuesta

13

¿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 a la base de datos directamente. Si el cliente tiene que usar una base de datos SQL en otro sistema, se prefiere el uso de un servicio web para una protección adicional y la ventaja adicional de tener una capa de negocios que debería ser capaz de manejar a múltiples usuarios.

¿Cuáles son los beneficios de conectarse a la base de datos desde la aplicación frente a usar un servicio web?

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

¿Cuál proporciona una mejor seguridad?

El uso de los servicios web tiende a ser más seguro, aunque la seguridad es a menudo más de una personas tema de edición del 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 irrelevante cuando el cliente y la base de datos están en el mismo sistema porque luego el usuario puede obtener acceso completo.

¿Qué tipo de alcance que llamar a uno contra el otro (intranet de la empresa frente a aplicación web, etc)

servicios web son mejores para aplicaciones cliente-servidor, donde los usuarios no deberían 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 por escribir 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 podría llamar a esta biblioteca directamente sin usar 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 solo crea una aplicación de escritorio con una base de datos local, escribir una biblioteca comercial con lógica para acceder a la base de datos es algo muy bueno. Su cliente puede llamar a esta biblioteca comercial directamente o a través de un servicio web, según sus necesidades.

¿Hay alguna otra consideración que sea necesaria al elegir en la plataforma?

Principalmente solo la cantidad de hardware que está dispuesto a usar para configurar las cosas. Si puede permitirse 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, entonces puede optar por la versión más estratificada, donde tanto el cliente como el sitio web llamar al servicio web, que llama a la base de datos. Pero si todo tiene que ejecutarse en un solo sistema, simplemente cúmplase con la aplicación y la capa/biblioteca comercial.

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.

+0

"ya que el usuario no puede acceder directamente a él": ¿qué sucede cuando el acceso a la base de datos se limita a la ejecución de procedimientos almacenados? Todos los SELECT/UPDATE/DELETE directos son denegados. ¿Existe un riesgo de seguridad en el nivel del puerto MS SQL que es más débil que el acceso al puerto del servidor web? – i486

15

La regla general es la siguiente:

  1. Escribir un conjunto de acceso de datos independiente que hablar con la base de datos.
  2. Si busca interoperabilidad entre diferentes plataformas/clientes, exponga este ensamblado como un servicio web SOAP.
  3. Si está buscando un rendimiento, utilice el ensamblaje directamente en sus aplicaciones cliente .NET.
+1

+1 para una respuesta breve y concisa. –

+0

¿Alguna razón específica para mencionar las aplicaciones .NET al final? –

3

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

Tiene múltiples tipos de clientes. Eso significa que su aplicación debe tener varias capas. No significa que necesite varios niveles.

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

7

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 la red entre la aplicación y el servidor Sql está abierta (normalmente el puerto tcp 1433), usaría la conectividad Sql.

3

Dado el contexto, puede haber una gran preocupación de seguridad con el acceso de los clientes a las bases de datos. Requiere que los usuarios accedan a la base de datos o que creen una cuenta de servicio. Darles a los usuarios acceso directo a la base de datos plantea riesgos. Ambos enfoques abren la puerta a la explotación de dll de escritorio para conectarse a db fuera del contexto de la aplicación (varias veces he visto casos donde hay una clase común de acceso a datos que todas las operaciones funcionales usan. 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 privados o protegidos, a menos que haga valer los privilegios de seguridad.

Los servicios web exponen operaciones funcionales que no exponen ninguna operación basada en sql. No solo es más seguro, sino que abstrae a su cliente de su implementación de almacenamiento de datos.

De nuevo, depende de su contexto. Sin embargo, en el ámbito Enterprise/ISV, generalmente es un gran no-no.

Cuestiones relacionadas