ADO .NET, C#

[Vassag0]

Bueno, pues aquí vuelvo con otra duda sobre programación. Y aprovechando que en la otra ocasión el maestro Findor me presto una inestimable ayuda, me lanzo con una nueva pregunta.

La duda se centra en el objeto DataTable del ADO .NET. En mi forma de trabajar no suelo usar DataSet, solo DataTable. No se si esto puede repercutir en algo negativo a la aplicación, pero normalmente es mi forma de trabajar.

El caso es que en la capa de acceso a datos de la aplicación, creo una DataTable y la "lleno" desde el DataAdapter. Hasta ahora creía que mi variable (pongamosle dataT) que almacenaba el DataTable creado, en cada consulta que hacía se reestablecia por completo.
Por ello he modificado mi código para asignar el nombre de la variable dataT según la necesidad de crear uno o varios hilos de consulta distintos.
Pero cual ha sido mi sorpresa que haciendo pruebas con el código antiguo, el que solo establece una DataTable, si yo establecía el dataT a mi tabla1 en el formulario1 y luego establecía el dataT a mi tabla2 en el formulario2. Llamando a dataT desde el formulario1 me seguía mostrando los datos de la tabla1, lo mismo que si llamaba al dataT desde el formulario2 mostraba los datos de la tabla2. Incluso haciendo un dataT.clear(); desde el formulario2, en el formulario1 seguía teniendo mis datos .
Vamos que a simple vista no parece hacer falta crear un DataTable para cada hilo de consulta.

Ahora me surgen las dudas. Principalmente se resume en una ¿Por qué pasa eso?
Yo pensaba que al volver a establecer la variable dataT y entregarle nuevos valores, pasaba como con cualquier variable, perdía los antiguos y cogía los nuevos.
¿Acaso el DataTable guarda un compendio de todas las tablas que abro? Pero ¿como sabe a cual me dirijo en cada formulario si en todos lo reclamo como dataT?

Si pudierais facilitarme información de por qué ocurre esto, o alguna pagina donde explique este comportamiento... Os lo agradecería un montón. Ya que ahora mismo no tengo claro cual sería la mejor manera de crear la capa de acceso a datos. Generando un DataTable para cada hilo, o un único para todas mis consultas.

 

[Archibald Alexander Leach]

Esto es debido a que en en cada formulario creas una instancia distinta del mismo objeto DataTable. Cada instancia tiene una existencia independiente dentro de su ámbito y reserva un espacio de memoria único para contener sus datos.

El objeto que declaras es sólo una estructura de datos con una serie de propiedades, pero que no existe en sí misma en memoria hasta que se instancia.

Recuerda que en teoría de objetos, éstos tienen una serie de características y propiedades que los diferencian de las simples variables.

 

[Vassag0]

Muchas gracias por tu respuesta.

Cierto, me olvidé que era un objeto.

Entonces ¿es valido usar dataT para cada una de las tablas de datos para el formulario?, en lugar de llamarla dataT1, dataT2...

De nuevo gracias.

 

[Findor]

Perdón por unirme tarde...

Los nombres no son importantes en los programas orientados a objetos, cada variable tiene su ámbito y tiene validez dentro de ese ámbito tal y como dice Archibald. Es decir, puedes tener algo así:

void a(...)
{
DataTable dt = new DataTable();
...
}

void b(...)
{
DataTable dt = new DataTable();
...
}

Si una variable la declaras dos veces para el mismo ámbito, el compilador ya se quejará.

 

[Vassag0]

Muchas gracias Findor.

En este caso la variable es publica. Su ámbito es toda la solución. Ya que se encuentra en la capa de datos.
Ya luego se le instancia desde distintos ámbitos.

Por ello no se que sería mas correcto si usar esto (al principio de la clase se estable data como public):

        #region Consulta de datos
        //Función para consultar datos segun la sentencia SQL dada
        public void consultar_datos(string consulta)
        {
            //Llamamos a la función de conexión a bbdd
            conectar();

            //Preparamos la captura de cualquier evento
            try
            {
                //Llenamos la tabla de datos procedentes de nuestra consulta
                da = new MySqlDataAdapter(consulta, conn);
                cb = new MySqlCommandBuilder(da);       

                data = new DataTable();

                da.Fill(data);
            }


            //ooopppss!!! no hay datos por esos criterios
            catch (InvalidCastException) { MessageBox.Show("La consulta no recupero datos con esos parametros","Sin Datos"); }

            //oopppss!!! no pudimos conectar
            catch (MySqlException ex) { MessageBox.Show("Error al conectar al servidor: " + ex.ToString(), "Error de Conexión"); }

        }
        #endregion


        #region Mostrar datos
        //Función para consultar datos segun la sentencia SQL dada
        public DataRow mostrar_datos(int f)
        {

            return data.Rows[f];

        }
        #endregion

o por el contrario:

        #region Consulta de datos
        //Función para consultar datos segun la sentencia SQL dada
        public DataTable consultar_datos(DataTable data, string consulta)
        {
            //Llamamos a la función de conexión a bbdd
            conectar();

                //Llenamos la tabla de datos procedentes de nuestra consulta
                da = new MySqlDataAdapter(consulta, conn);
                cb = new MySqlCommandBuilder(da);

                data = new DataTable();

                da.Fill(data);

                return data;

        }
        #endregion


        #region Mostrar datos
        //Función para consultar datos segun la sentencia SQL dada
        public DataRow mostrar_datos(int f, DataTable datatable)
        {
            return datatable.Rows[f];

        }
        #endregion

 

[Findor]

Yo no soy partidario de las variables globales, son más cómodas porque no tienes que irlas pasando como parámetro, pero suelen ser un quebradero de cabeza.

Con variables locales siempre sabes donde están y sabes que si se llenan con datos incorrectos es porque los métodos que las usan no hacen lo que toca.

A los programadores que están a mi cargo siempre les digo que las variables globales son de cobardes...

 

[Vassag0]

Pues haré caso a los maestros y me quedo con variables locales.

Ciertamente las variables globales pueden jugartela fácilmente. Pero es que son tan cómodas...

Muchas gracias a ambos por la aclaración y los consejos.