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

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:
Mostrar la cita

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

El objetivo real de las tecnologias .NET es dominar el software sobre
internet de manera eficaz. Los Web Service son el verdadero punto que hace
notable a .NET frente a las pasadas tecnologias (a COM+ me refiero).

En ralidad el rendimiento no de mide tanto por la tecnologia aplicada, como
por los requerimientos de volumen de datos que se pasan por internet, - y el
ancho de banda disponible por supuesto. Sin embargo, en igualdad de
condiciones .NET 2005 mejoro mucho en cuanto a la respuesta y experiencia
final del cliente.


Saludes,
<Harvey Triana/>


"Developers" escribió en el mensaje
news:
Mostrar la cita

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

Contesto entre Lineas

Jesús López escribió:
Mostrar la cita

Me faltaría alguna información para dar una respuesta más a medida.

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

Actualmente No estan interconectadas entre si, la comunicación es Via Email.
Mostrar la cita

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

Todas las Oficinas estan Usando Internet Banda Ancha
Mostrar la cita

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

Cada Oficina Tiene su Data Trabajada en Msde2000 y la Prinpal cuenta con Sql Server 2000
Standar, pero necesita que la Data que ellos tienen tambien tenga la oficina Principal
(Cualquier Cambio que exista de Informacion debe estar reflejada en la Principal pero si
la Principal hace Su cierre Mensual las demas Oficinas No podran tocar esa información mas
que verla solamente.
La principal solicita que la información sea Reflejada en Cualquier Momento (NO quieren
Información Actualizada al Final del Dia)
Mostrar la cita

¿De cuantos usuarios estaríamos hablando?

Ahorita de 70 Usuarios pero puede seguir creciendo
Mostrar la cita

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:

Mostrar la cita

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

Claro... Gracias a Uds. Uno puede ir teniendo las cosas mas claras.


Oscar Roberto Onorato escribió:
Mostrar la cita

Dany,

Yo por mi parte puedo decirte esto:

¿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?
Sólo usarlo cuando es necesario. Pues el costo de performance siempre
recae en el server en lo que a este Objeto respecta.

Con respecto a las consultas para reportes es posible realizarlas
simplemente con un Reader() del tipo de objeto necesario, ya sean para
datos de una BD o de un XML. Son sin duda los métodos de consulta más
rápidos y menos costosos.

¿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?

Como respondieron en este mismo thread, usar WebServices también va a
ser más conveniente por el simple hecho de mantenerte dentro del código
administrado del .NetFrameWork, lo que habrá que revizar son los tiempos
de desarrollo, para saber si es posible incrustar el COM+ dentro del
proyecto, o si es posible tomarse el tiempo de desarrolla el WebService
realmente, lo cual permitiría que desarrolles sobre el mismo entorno y
los beneficios del cóodigo administrado.

Pero vale aclarar algo Dany. Es mi opinión, en este foro hay mucha gente
que sabe mucho, y sobre todo mucho más que quién te escribe, así que
tomalo así, como una opinión pues es lo que yo me plantearía, entre
otras cosas.

Saludos y espero que te haya servido.

"Developers" <mailto:
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

En ese caso yo montaría una replicación transacional con colas o una
replicación de mezcla en SQL Server ya que es un escenario muy típico para
replicación. Por otra parte crearía aplicaciónes Windows que accedieran al
SQL Server local, nada de servicios web ni COM+.

El publicador y distribuidor de la replicación sería el servidor SQL Server
central y los MSDE 2000 de las oficinas serían los subscriptores.

Tanto en replicación transacional con colas como en la replicación de mezcla
puede tenerse un retraso en la actualización de los datos muy pequeño y en
los dos casos se puede seguir trabajando normalmente aunque falle la
conexión a internet. Para mayor seguridad sería recomendable montar una red
privada virtual, aunque esto no es necesario porque la replicación de mezcla
puede sincronizarse por IIS usando el protocolo HTTPS.

Saludos

Jesús López
MVP


"Developers" escribió en el mensaje
news:
Mostrar la cita

Contesto entre Lineas

Jesús López escribió:
Mostrar la cita

Me faltaría alguna información para dar una respuesta más a medida.

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

Actualmente No estan interconectadas entre si, la comunicación es Via
Email.
Mostrar la cita

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

Todas las Oficinas estan Usando Internet Banda Ancha
Mostrar la cita

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

Cada Oficina Tiene su Data Trabajada en Msde2000 y la Prinpal cuenta con
Sql Server 2000 Standar, pero necesita que la Data que ellos tienen
tambien tenga la oficina Principal (Cualquier Cambio que exista de
Informacion debe estar reflejada en la Principal pero si la Principal hace
Su cierre Mensual las demas Oficinas No podran tocar esa información mas
que verla solamente.
La principal solicita que la información sea Reflejada en Cualquier
Momento (NO quieren Información Actualizada al Final del Dia)
Mostrar la cita

¿De cuantos usuarios estaríamos hablando?

Ahorita de 70 Usuarios pero puede seguir creciendo
Mostrar la cita

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:

Mostrar la cita

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