Boletín mugperu Digital - Julio 2009!
  Search 
Thursday, February 09, 2012 ..:: Foros de Discusión ::.. Register  Login
Foros MUGPERU Minimize
Subject: Conexion en los Datareader
Prev Next
You are not authorized to post a reply.

Author Messages
DeveloperNet2005
Posts:18

24/05/2005 02:44 PM  

Una Duda, tengo una clase que tiene varias funciones que devuelven Datareader, para que este funcione la conexion debe estar abierta ni tampoco puedo usar esa misma conexion cuando invoco a otra funcion de la misma, mi preguta debo crear una conexion en cada una de estas funciones??

Saludos

richie_crazy57
Posts:203

25/05/2005 09:37 AM  

Hola DeveloperNet2005:

Me parece muy acertada tu apreciación. Creo que la solución más adecuada (no estoy seguro) sería crear una clase propia de conexión (que herede de SqlConnection o OleDBConnection o la implementación de conexión del proveedor de datos que utilices).

Como debes sabet, por cuestión de buenas prácticas es recomendable mantener en una sola ubicación los datos de la conexión a tu BD para facilitar el mantenimiento y modificación.

Implementando tu clase de conexión tendrías esas 2 ventajas: facilitar el mantenimiento y permitir la ejecución de instancias múltiples de la misma. En cada método simplemente crearías una instancia de tu clase y listo...

Я!©ђ!Є ©Я∆ZΨ

manueell
Posts:29

25/05/2005 11:20 AM  

Hola

Estaba leyendo este mensaje, y no creo que sea una solución que estoy dando más bien una experiencia al momento de desarrollar, y tengo una curiosidad, yo usé funciones que devuelvan Datareader en una clase, pero la conexión debe estar abierta y después de usar el DataReader la cierro. Pero cuando use por ejemplo una clase de estan todos mis funciones con DataReaders, y otra clase para el acceso a Datos, o sea donde esta SqlConnecction, al momento de ejecutar me sale un error que dice "Que esta cerrada la conexión" o algo similar, textualmente no recuerdo el mensaje que apareció pero se referida que la conexión tendría que estar abierta para usar el datareader. 

En ese entonces opte por usar DataTable, sé que no es lo mismo, pero me daba los resultados, sería bueno que alguien tenga una idea de como se pudiera solucionar esto o que enseñe un link donde esta un caso igual o similar. Porque para tener un mejor rendimiento optaría por usar un DataReader, pero cómo dije que no tenía resultado, opte por el DataTable.

Gracias por la atención, prestada.

Atte.
Manuel Sánchez

 


Manuel Sánchez
===============
Analista Programador
manueell@gmail.com
DeveloperNet2005
Posts:18

26/05/2005 08:39 AM  

Exacto los Datareader consumen menos recursos que los Datasets , pero debes tener la conexion abierta (ese no es problema) pero te restringe que puedas usar esa conexion en otra operacion de acceso a datos. Entonces eso me "obligaria" a crear conexiones locales es decir en cada metodo, mi pregunta eso es asi o hay otra solucion.

Saludos

richie_crazy57
Posts:203

26/05/2005 11:26 AM  

Hola, DeveloperNet2005:

Primero que nada, quiero pedir disculpas por si alguien siguió mi consejo acerca de heredar la conexión y aplicarle una connectionString fija. Esto es imposible (por lo menos a primera vista), dado que la clase SqlConnection está declarada como NotInheritable (no heredable), lo mismo que la clase OleDbConnection, y asumo que las demás también.

Siendo así, hice lo siguiente: creé otra clase personalizada de conexión, creé dentro de ella un objeto de tipo SqlConnection e implementé en esa clase personalizada la interfaz IdbConnection. Luego, para cada uno de los miembros (métodos y propiedades) de la interfaz llamaba a sus implementaciones en el objeto SqlConnection (incluso implementé algunos métodos y eventos propios de la clase SqlConnection). Finalmente, le asigné en el constructor sin parámetros la cadena de conexión fija para que el objeto SqlConnection apuntara siempre a mi base de datos.

Una vez hecho esto, muy contento fui a mi aplicación cliente, llamé a la clase en cada uno de los métodos y aparentemente funcionaría. Sin embargo, cuando creé el SqlCommand y le asigné como conexión el objeto de mi clase de conexión, me resaltó el error. Esto se debe a que el SqlCommand necesita de un objeto de tipo SqlConnection (y obvio que mi clase no lo era, a pesar de que implementaba casi todos sus miembros, dado que no heredaba de la misma).

Por un momento se me cruzó por la cabeza la idea de crear mi comando personalizado. Pero me di cuenta de que iba a terminar haciéndole su data reader personalizado, quizás luego parámetros, data adapters, ... y no iba a acabar nunca.

Lo peor de todo es que mi solución (si es que hubiera funcionado) hubiera sido más de lo mismo, ya que no era más que instanciar una conexión dentro de cada método, que es lo mismo que estabas haciendo, no?

Por el momento, me parece que es la única manera. Espero que si alguno de nuestros compañeros del MUG conoce otra alternativa mejor, nos pueda orientar.

Bye.

Я!©ђ!Є ©Я∆ZΨ
Lduenas
Posts:25

27/05/2005 11:06 AM  

Hola:

Creo que antes de escribir el codigo deberiamos reflexionar un poco sobre el uso y caracteristicas de cada objeto, en este caso d e ADO .NET. A continuacion algunas diferencias:

1. DataReader

- Es muy rapido por almacenar un solo registro a la vez.

- La conexion siempre debe estar abierta para trabajar con el objeto DataReader (Esquema Conectado).

- No es actualizable, es de solo lectura (Read Only)

- Es de avance solo hacia adelante (Forward Only)

- No es enlazable a Controles Windows Forms NET, si a los controles Web Forms NET.

- Permite leer varios Select usando el método NextResult para obtener los demas conjuntos de resultados.

- Permite leer y escribir sobre campos con imagenes (binarios) en Bases de Datos, etc.

- Es usado en Aplicaciones Windows Cliente/Servidor 2 niveles donde se necesita velocidad y no existe problemas con el numero de conexiones que maneja el Servidor.

- No es serializable, es decir no puede pasar como XML entre capas o niveles (Tiers) en una solucion remota.

2. DataSet

- Es mas pesado por almacenar todos los registros.

- La conexion siempre esta cerrada al trabajar con el objeto DataSet (Esquema Desconectado).

- Es actualizable mediante el metodo Update

- Es desplazable en todos los sentidos, en Windows se usa el objeto CurrencyManager.

- Sus miembros (DataTables y DataViews) son enlazables a Controles Windows Forms y Web Forms.

- Permite leer un solo Select en una Tabla, aunque esta traiga datos de varias.

- No permite leer y escribir sobre campos con imagenes (binarios) en Bases de Datos, etc.

- Es usado en Aplicaciones de N capas o niveles donde se necesita interoperabilidad entre plataformas y exista problemas con el numero de conexiones que maneja el Servidor.

- Por ejemplo es usado en aplicaciones de 3 niveles con COM+ o NET Remoting. Tambien es muy usado en Aplicaciones Web y Servicios Web XML

- Es serializable, es decir se pasa como XML entre capas o niveles (Tiers) en una solucion remota.

Consejo

- Si vas a usar datos dentro de componentes recuerda que van a ser llamados por multiples usuarios lo cual implica que debes trabajar en un esquema desconectado (DataSet).

- No interesa si tecnicamente puedes heredar o implementar tu propia clase de acceso a datos "Conectada" que use "DataReaders". Esta implementacion debe estar pensada en la arquitectura en la cual se va a desarrollar.

Post Data

En la version 2.0 de ADO NET, la que viene con el Visual Studio NET 2005 (Whidbey) ya existe un objeto llamado el DataTableReder que combina la funcionalidad del DataReader en un esquema desconectado (DataSet).

Saludos:

MCT Luis Dueñas.

dotNetPeru
Posts:13

24/08/2005 12:17 AM  

  Me parece, si es que entendi bien el problema, pero normalmente no es recomendable pasar el DataReader a traves de clases, porque como ya dijeron todos tendrias que mantener tu conexion abierta. Tampoco es recomendable usar DataSet por su reconocido alto consumo de recursos, como tambien lo han dicho en los otros post.
  Lo que normalmente se suele usar (si has ido a alguna de las charlas de Christiam E.), es crear Entidades de Negocios, que son simplemete clases que representan a los datos que quieres traer (p.ej. la clase Usuario que representa a una fila de tu tabla usuarios) y pasarlos del DataReader a una lista de objetos de tu entidad de negocio (en el ejemplo IList , ArrayList de Usuario) y esa lista es la que pasas entre tus clases o capas en tu aplicacion.
  Revisa en Downloads del MugPeru, algunas de las charlas de Christiam, en alguna Aplicaciones distribuidas, u otra debe haber un ejemplo.

Saludos
dotNetPeru

You are not authorized to post a reply.
Forums > Temas de Interés > Usando ADO.NET > Conexion en los Datareader



ActiveForums 3.7
        
Copyright 2001-2012 MUGPERU   Terms Of Use  Privacy Statement