Objetos ADO.NET

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

"Eduardo Alvarado Meza" <ealvarado_15@(eliminarestetexto)hotmail.com>
escribió en el mensaje news:

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.

Hola, Eduardo:

Es peligroso "etiquetar" los conceptos. Al final, las discusiones derivan
hacia la propiedad de las etiquetas y se desvian de los conceptos.

Un Datareader es una interfaz con un cursor de acceso secuencial y
sólo-lectura del lado del servidor. En la medida en que depende de la
conexión con que se generó, es un objeto "conectado". Un Command no puede
funcionar sin una conexion abierta. Puedes (y normalmente debes, si quieres
realizar actualizaciones) asignarle una transaccion a un Command. Y puedes
reutilizarlo dentro de la misma transacción, con solo reiniciar su lista de
parametros y asignarle los valores necesarios a CommandText y CommandType.
Tambien es un objeto "conectado"

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.

La manera de controlar los bloqueos con proveedores SQL es mediante las
transacciones. Si inicias una transaccion y modificas un registro, ese
registro (o la pagina que lo contiene, con algunos gestores) queda
bloqueada. La lógica de bloqueos está definida por el proveedor de datos.
ADO.NET es solo una interfaz con el proveedor.

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.

Los adaptadores son esencialmente objetos desconectados. Los comandos solo
funcionan si tienen una conexion. Son cosas diferentes.

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?

Creo que la diferencia esencial es una de estilo.

Cuando tienes un sistema de proceso de transacciones en linea, casi siempre
debes asegurarte de que la información sobre la que estas trabajando refleja
el estado actual de los objetos representados.

Los datos pueden clasificarse tambien según su volatilidad o estabilidad: la
existencia de un articulo de alta rotación es sumamanete volatil. Otros,
como los saldos de las cuentas corrientes de un banco, no son tan volatiles,
pero son tan criticos que es conveniente verificarlas antes de cada
transaccion:

UPDATE Cuentas SET Saldo = Saldo - @MontoRequerido,
Disponible = Disponible - MontoRequerido
WHERE CodigoCuenta = @CodigoCuenta
AND Disponible + LimiteCredito < @MontoRequerido;
SET @ok = SELECT @@RECORDSAFFECTED;

y en caso de que @ok = 0 determinas cual fue la causa del fallo: normalmente
un sobregiro.

Otros datos, como las tasas de interes, tipos de cambio, tipos de descuento,
condiciones de venta, etc. son mas estáticos.

Creo que la diferencia entre "Objetos Conectados" y "Objetos Desconectados"
es un concepto útil para decidir el tipo de objetos a utilizar en la
implementacion. Por ejemplo, los conjuntos de datos reducidos y poco
volatiles vienen de perlas en un DataAdapter. Pero las cuentas, existencias,
precios de articulos deben ser cargadas en el momento de la validacion.
Igual puedes agregar o eliminar tablas a un adaptador, pero en esos caso
viene de perlas un DataReader. Igual para el registro de operaciones,
encuentro muchísimo mas natural Abrir una Conexion, crear un objeto Command,
iniciar una transaccion sobre la conexion, asignarla al Command y emitir una
serie de consultas de acción a través de éste que actualizar entradas en un
DataTable contenido en un DataAdapter. La posibilidad de controlar la
transaccion es vital.

Tambien tengo que reconocer que no sé en detalle cómo funciona un
DataAdapter, simplemente porque "migré" un modelo conceptual que vengo
arrastrando los ultimos veinte años. Lo unico que puedo decirte es que lo
encuentro mucho mas complejo que la emision directa de comandos SQL a traves
de un Command o que el uso de DataReaders. Y por lo que acabo de ver en la
documentacion, no te ofrece la garantia de «Todos o Ninguno» que dan las
transacciones (tienes que llamar a GetChanges para saber qué pasó), de
manera que veo complicado -y torpe- su uso para aplicaciones OLTP.

Por otra parte, para cada tabla debes definir los comandos SQL que se usarán
para Actualizar, Eliminar o Insertar nuevos registros, de manera que no
"ganas" nada con respecto al uso de instrucciones dinamicas o llamadas
directas a SPs.

En fin, que sí creo que hay diferencias entre trabajar localmente
(desconectado) o trabajar directamente contra el servidor (desconectado), y
tambien que el último metodo tiende a ser mas eficiente. Sobre todo, la
reflexión sobre ambos modelos (y la discusion es parte de la reflexion) es
vital para el establecimiento de una metodología sólida.

Pero es solo una opinión.


Salud!

Interesante, y todo lo que dijistes es verdad, ya lo sabia pero creo que lo
agarre por el lado equivocado, falta de razonamiento, lo de todo o ninguno
tambien es interesante y una realidad.

Reseteare un poco el disco. Gracias