Es conveniente Usar Dataset como Contenedor de Datos para un Entorno Cliente Servidor???

04/02/2006 - 17:22 por Developers | Informe spam
Amigos estoy a punto de iniciar un Proyecto en VB.Net 2003(Puede ser 2005)+ SQL2000 bajo
entorno Cliente/Servidor(Capas Datos+Capa Logicas+Interfaces+Interconexion de Oficinas de
Todo el Pais), pero mi duda es lo siguientes:

Es conveniente Trabajar con Dataset toda la aplicacion bajo este entorno o Solamente usar
Dataset cuando sean necesarios(Reportes,algunas Consultas)???

Eso influira en el Rendimiento de la aplicación Local / Remoto??

Para Trabajar con Data Interconectada en todo el Pais es conveniente Trabajar con
WebServices o que la Aplicacion pueda usar Directamente Com+ de la Central???


ojala me puedan orientar y sacarme algunas dudas...

Gracias

Developers - Dany Acosta
 

Leer las respuestas

#1 Jesús López
04/02/2006 - 19:36 | Informe spam
Me faltaría alguna información para dar una respuesta más a medida.

¿Cómo están interconectadas las oficinas?.

¿Todas las oficinas tienen conexión de banda ancha a Internet?

¿Cómo están distribuidos los datos? ¿Las oficinas tienen sus propios datos
en su propio SQL Server local?

¿De cuantos usuarios estaríamos hablando?

Dependiendo de las respuestas a estas preguntas, la arquitectura más
adecuada sería distinta. Hay varias opciones:

(1) Replicación. Tener SQL Server locales que son subscriptores de una
publicación del Servidor SQL Server central. Las aplicaciones sólo tendrían
que acceder al servidor local. Los servidores locales podrían ser incluso
MSDE 2k o SQL Server 2005 Express. Esta arquitectura tiene la ventaja de
que las oficinas podrían seguir trabajando incluso cuando se perdiera la
conexión a Internet.

(2) Un único servidor SQL Server central. Las aplicaciones cliente
accederían a un servicio web de la oficina central o a COM+ o a .NET
Remoting . Sin embargo COM+ sólo sería una opción viable si las oficinas
estuvieran interconectadas por una red dedicada o mediante una VPN por
Internet. Además COM+ es engorroso de desplegar y la gestión de versiones no
es tarea trivial. Así que web services sería seguramente la opción más
deseable.


En cuanto a usar DataSets o no, yo particularmente pienso que los datasets
definidos (strong typed) son una buena opción en la mayoría de los casos. La
alternativa, que sería usar objetos de negocio, que no son más que clases
que mapean sus propiedades con campos de la base de datos, son más livianos
que los DataSets. Pero la ligereza de los objetos de negocio tiene un precio
que es un mayor tiempo de desarrollo y una menor funcionalidad. Los datasets
tienen capacidades de filtrado, ordenación y búsqueda, enlace a controles y
soporte para la gestión optimista de la concurrencia. Para los objetos de
negocio habría que escribir un montón de código para dotarles de esta
funcionalidad y si se hace así, entonces se pierde su ligereza y además
terminan pareciéndose mucho a los datasets definidos. Por estas razones, yo
personalmente prefiero usar Datasets definidos desde el principio, en la
mayoría de los casos su pesadez comparada con la ligereza de los objetos de
negocio no supone una pérdida de rendimiento lo suficientemente apreciable
como para ser considerada.

Si te decides por usar servicios web. Hay un par de recomendaciones que se
deberían seguir:

(1) Usar dataset definidos. Es conveniente que las aplicaciones cliente
conozcan el esquema de los datasets usados. Usando datasets definidos el
esquema está presente en el documento WSDL del servicio web.
(2) Usar DataSet.GetChanges(). A la hora de guardar los datos, las
aplicaciones cliente deberían enviar sólo los cambios, no el dataset entero.
Esto reduce el tráfico de red y el procesamiento en el servidor web.
(3) Usar Dataset.SchemaSerializationMode = ExcludeSchema. Si las
aplicaciones ya conocen el esquema de los dataset, no hay razón alguna para
enviar el esquema cada vez que se envia un dataset. Esto reduce el tráfico
de red
(4) Comprimir el tráfico HTTP. El servidor web, puede comprimir todo el
tráfico HTTP de salida. Esto aumenta bastante el rendimiento de las
aplicaciones al reducir considerablemente el tráfico de red. En este blog se
explica como configurar IIS 6.0 para que comprima el tráfico HTTP:
http://weblogs.asp.net/owscott/arch...57916.aspx . El proxy del
cliente tendría que tener la propiedad EnableDecompression = True. Lástima
que no haya compresión automática de los datos que van desde el cliente al
servidor. Sin embargo esto puede conseguirse mediante extensiones soap.


NOTA: las recomendaciones (3) y (4) sólo están disponibles en .NET Framework
2.0. En .NET Framework 1.1 se puede conseguir compresión en los dos sentidos
usando extensiones soap.

Saludos:

Jesús López
MVP


"Developers" escribió en el mensaje
news:
Amigos estoy a punto de iniciar un Proyecto en VB.Net 2003(Puede ser
2005)+ SQL2000 bajo entorno Cliente/Servidor(Capas Datos+Capa
Logicas+Interfaces+Interconexion de Oficinas de Todo el Pais), pero mi
duda es lo siguientes:

Es conveniente Trabajar con Dataset toda la aplicacion bajo este entorno o
Solamente usar Dataset cuando sean necesarios(Reportes,algunas
Consultas)???

Eso influira en el Rendimiento de la aplicación Local / Remoto??

Para Trabajar con Data Interconectada en todo el Pais es conveniente
Trabajar con WebServices o que la Aplicacion pueda usar Directamente Com+
de la Central???


ojala me puedan orientar y sacarme algunas dudas...

Gracias

Developers - Dany Acosta

Preguntas similares