Objetos ADO.NET

28/03/2006 - 01:18 por Hugo Gsell | Informe spam

Según el libro de "Programación avanzadada con microsoft visual basic .NET"
de Francesco Balena (Mac Graw Hill), con respecto a los objetos de ado.net,
el objeto dataset es el principal objeto de la arquitectura desconectada de
.net... es decir, crea digamos una pequeña base de datos "local" para
trabajar...
esto crearía una "capa" adicional entre los datos reales y mi aplicación
con su respectivo consumo de recursos...
Es decir, que si necesito utilizar ado.net en un ambiente multiusuario pero
local (digamos una típica aplicación empresarial facturación ctas corrientes
stock)
debería utilizar el objeto command y datareader del objeto Connection (ver
esquema) a fin de que sea "mas directa" y trabajar con bases conectadas?
O sea,
¿Puedo deducir entonces que debería utilizar los objetos command y
datareader para acceder en "modo conectado" a la base de datos?
El esquema que presenta balena es así...
_________________________________ _________________
|CONNECTION < ==> DATAADAPTER <=|=> DATASET |
| | | |
|
| V | |
|
|COMMAND | |
|
| | | |
|
| V | |
|
|DATAREADER | |
|
|________________________________| |_______________|
Hugo A. Gsell
Sgo del Estero
Argentina

Siga el debate

3 respuestas

Tengo una respuesta

DRAGON AGE™: INQUISITION – Matadragones

Leer las respuestas

#1 Eduardo Alvarado Meza

28/03/2006 - 06:17 | Informe spam

Los libros de Balena tienen gran trascendencia y son muy entendibles pero me
sorprende que el diga eso, porque tengo "entendido" que en el ADo.net el
modelo conectado no existe, nada tiene que ver los comandos, los adaptadores
y los datasets. Los datareader podrian ser los mas cercanos pero solo son
para leer rapidamente.

No importa que sea local o no, el ado.net es desconectado, por ejemplo, no
existe el bloqueo de registro como en ado con access, solo se disparan
excepciones de errores de concurrencia y tu te encargas de darle
tratamiento.

Otro detalle que deberias tomar en cuenta es que tanto los comandos como los
adaptadores la mayoria de las veces trabajan juntos, asi que no se puede
decir que uno es para un modelo y otro para el otro.

Ahora suponiendo que uses solo comandos, traerias los datos con ellos,
ESPEREARIAS que el usuario los actualize, y si los actualizas utilizas otro
comando para hacer el update, Cual seria la diferencia con el modelo
desconectado?

"Hugo Gsell" escribió en el mensaje
news:

Según el libro de "Programación avanzadada con microsoft visual basic
.NET" de Francesco Balena (Mac Graw Hill), con respecto a los objetos de
ado.net, el objeto dataset es el principal objeto de la arquitectura
desconectada de .net... es decir, crea digamos una pequeña base de datos
"local" para trabajar...
esto crearía una "capa" adicional entre los datos reales y mi
aplicación con su respectivo consumo de recursos...
Es decir, que si necesito utilizar ado.net en un ambiente multiusuario
pero local (digamos una típica aplicación empresarial facturación ctas
corrientes stock)
debería utilizar el objeto command y datareader del objeto Connection (ver
esquema) a fin de que sea "mas directa" y trabajar con bases conectadas?
O sea,
¿Puedo deducir entonces que debería utilizar los objetos command y
datareader para acceder en "modo conectado" a la base de datos?
El esquema que presenta balena es así...
_________________________________ _________________
|CONNECTION < ==> DATAADAPTER <=|=> DATASET |
| | |
| |
| V | |
|
|COMMAND | | |
| | |
| |
| V | |
|
|DATAREADER | | |
|________________________________| |_______________|
Hugo A. Gsell
Sgo del Estero
Argentina

Leer las otras respuestas

Preguntas similares

Busqueda sugerida :