Datatable tipada y Linq

"Beto" wrote in message
news:ungXa2S%

Yo quisiera hacer una clase nombrada RegistroVariable que mandandole a su
constructor un nombre de tabla y una clave primaria INT (identity) de una
tabla de mi base de datos me retorne un objeto (que podria ser un
datatable tipado) que me incluya en sus propiedades los nombres de los
campos de esa tabla y en sus valores los valores de dichos campos.

Ejemplo:

RegistroVariable Reg=New RegistroVariable("Tabla1",14567); /*1457 es la
clave primaria de la tabla Tabla1*/

Ejemplo: La estructura de Tabla1 es PK (int), TrFec (datetime), TrNo
(int), TrDet (char(40)

Yo quiero que me retorne en Reg esos mismos campos de manera que pueda
acceder a ellos
de la forma Reg.PK, Reg.TrFec, Reg.TrNo, Reg. TrDet.

Es problemático. Para que puedas hacer Reg.LoQueSea, el compilador tiene
que conocer ese "LoQueSea", pero si se define en tiempo de ejecución en
función del string "Tabla1", no se conoce en tiempo de compilación.

Lo más parecido sería Reg("PK"), Reg("TrFec"), etc., pero esto sería
simplemente un DataRow de un DataTable no tipado, el cuál podrías llenar de
forma bastante simple con un Fill de un DataAdapter.

Por cierto alguien me dijo que con Linq en la proxima version eso se hace
mas sencillo ? Es cierto? me podrian decir como ?

No es solo Linq, sino también el C# versión 3. En esta versión puedes
declarar tu variable Reg como var Reg=Expresion;, y luego usar Reg.LoQueSea,
pero para eso todos los campos tienen que ser conocidos dentro de Expresion,
no puede ser un string que se resuelva sobre la marcha. Pero lo que sí
tienes es que Visual Studio 2008 the permite definir de forma gráfica un
origen de datos que abarque todas las tablas que quieras de la base de
datos, y luego puedes hacer Select en tu código desde el origen de datos, y
te reconoce las columnas como quieres (pero la tabla la tienes que poner
fija, no puede ser un string).

Es problemático. Para que puedas hacer Reg.LoQueSea, el compilador
tiene que conocer ese "LoQueSea", pero si se define en tiempo de ejecución
en función del string "Tabla1", no se conoce en tiempo de compilación.

Lo más parecido sería Reg("PK"), Reg("TrFec"), etc., pero esto sería
simplemente un DataRow de un DataTable no tipado, el cuál podrías llenar
de forma bastante simple con un Fill de un DataAdapter.

Ok, me bastaría con eso: Reg["PK"] o Reg["TrFec"] ya que no podría usar
directamente Reg.PK y Reg.TrFec (la verdad no entiendo por qué si para los
fines es lo mismo).
Pero pregunto, que problemas da ?, no se si de rendimiento o de tipos yo
usar ese forma Reg["NombreCampo"] dondequiera que yo desee acceder ese valor
o modificarlo en vez de tener que definir una clase tipada para cada tipo de
registro distinto? No se recomienda? Hay que hacer unbox o casting de tipos
para usar cada valor de las columnas de Reg?

No es solo Linq, sino también el C# versión 3. En esta versión puedes
declarar tu variable Reg como var Reg=Expresion;, y luego usar
Reg.LoQueSea, pero para eso todos los campos tienen que ser conocidos
dentro de Expresion, no puede ser un string que se resuelva sobre la
marcha. Pero lo que sí tienes es que Visual Studio 2008 the permite
definir de forma gráfica un origen de datos que abarque todas las tablas
que quieras de la base de datos, y luego puedes hacer Select en tu código
desde el origen de datos, y te reconoce las columnas como quieres (pero la
tabla la tienes que poner fija, no puede ser un string).

Bien pero lo que hace es generar el codigo por mi no ? es decir crear un
dataset tipado y los datatables tipados , no es asi? Si lo es pues es igual
y lo quería evitar.

Finalmente cuando digo que el nombre de tabla se manda como string es con la
idea de armar un select en un string.
Algo parecido a: "select * from "+cNombreTabla+" where
PK="+nValorPK.ToString().Trim()



Muchas gracias por la ayuda tocayo :)

Beto

Beto

"Beto" wrote in message
news:OA0zLUe%

[...]
Lo más parecido sería Reg("PK"), Reg("TrFec"), etc.,

[...]
Ok, me bastaría con eso: Reg["PK"] o Reg["TrFec"] ya que no podría usar
directamente Reg.PK y Reg.TrFec (la verdad no entiendo por qué si para los
fines es lo mismo).

No, para los fines NO es lo mismo. En el caso de Reg["PK"], si pones
cualquier cosa entre las comillas el programa compila sin errores, pero
"casca" al ejecutarlo. En el caso de Reg.PK, el intellisense te ofrece los
valores disponibles, y el compilador te da un error si pones un valor
incorrecto.

Pero pregunto, que problemas da ?, no se si de rendimiento o de tipos yo
usar ese forma Reg["NombreCampo"] dondequiera que yo desee acceder ese
valor o modificarlo en vez de tener que definir una clase tipada para cada
tipo de registro distinto?

No, problemas de rendimiento no es probable que tenga. La pequeñísima
cantidad de tiempo que pierdan las rutinas en buscar el campo por su nombre
es insignificante en comparación con el coste que tiene recuperar
previamente el registro desde la base de datos. El principal motivo por el
que se recomienda no usar esta construcción es precisamente el de que los
errores solo se detectan en tiempo de ejecución, no en tiempo de
compilación.

No se recomienda? Hay que hacer unbox o casting de tipos para usar cada
valor de las columnas de Reg?

Sí, si usas esta construcción hay que hacer un cast del Reg[campo] al
tipo de la variable a la que lo asignas, y esto es otra operación más que
puede fallar en tiempo de ejecución sin que te lo detecte antes el
compilador.

[...Linq...]

Bien pero lo que hace es generar el codigo por mi no ? es decir crear un
dataset tipado y los datatables tipados , no es asi? Si lo es pues es
igual y lo quería evitar.

No, el Linq no funciona asi. El código de selección de datos lo tienes
que escribir tú, y lo que ocurre es que el compilador produce directamente
clases que encapsulan los resultados de la consulta. No hay datasets ni
datatables por ningún lado.

Finalmente cuando digo que el nombre de tabla se manda como string es con
la idea de armar un select en un string.
Algo parecido a: "select * from "+cNombreTabla+" where
PK="+nValorPK.ToString().Trim()

Sí, si. Eso se lo puedes meter al CommandText del SelectCommand de un
DataAdapter, con él haces un Fill de un DataTable, y devuelves el Rows[0] de
ese DataTable. Sobre ese DataRow devuelto (llamémosle Reg) ya puedes
preguntar por el Reg["TrFec"] y demás columnas, como querías.

Respuesta de lujo! Ya entendí bien.

De nuevo, muchas gracias.

Beto


"Alberto Poblacion"
escribió en el mensaje news:uFuY68e%

"Beto" wrote in message
news:OA0zLUe%

[...]
Lo más parecido sería Reg("PK"), Reg("TrFec"), etc.,

[...]
Ok, me bastaría con eso: Reg["PK"] o Reg["TrFec"] ya que no podría usar
directamente Reg.PK y Reg.TrFec (la verdad no entiendo por qué si para
los fines es lo mismo).

No, para los fines NO es lo mismo. En el caso de Reg["PK"], si pones
cualquier cosa entre las comillas el programa compila sin errores, pero
"casca" al ejecutarlo. En el caso de Reg.PK, el intellisense te ofrece los
valores disponibles, y el compilador te da un error si pones un valor
incorrecto.

Pero pregunto, que problemas da ?, no se si de rendimiento o de tipos yo
usar ese forma Reg["NombreCampo"] dondequiera que yo desee acceder ese
valor o modificarlo en vez de tener que definir una clase tipada para
cada tipo de registro distinto?

No, problemas de rendimiento no es probable que tenga. La pequeñísima
cantidad de tiempo que pierdan las rutinas en buscar el campo por su
nombre es insignificante en comparación con el coste que tiene recuperar
previamente el registro desde la base de datos. El principal motivo por el
que se recomienda no usar esta construcción es precisamente el de que los
errores solo se detectan en tiempo de ejecución, no en tiempo de
compilación.

No se recomienda? Hay que hacer unbox o casting de tipos para usar cada
valor de las columnas de Reg?

Sí, si usas esta construcción hay que hacer un cast del Reg[campo] al
tipo de la variable a la que lo asignas, y esto es otra operación más que
puede fallar en tiempo de ejecución sin que te lo detecte antes el
compilador.

[...Linq...]

Bien pero lo que hace es generar el codigo por mi no ? es decir crear un
dataset tipado y los datatables tipados , no es asi? Si lo es pues es
igual y lo quería evitar.

No, el Linq no funciona asi. El código de selección de datos lo tienes
que escribir tú, y lo que ocurre es que el compilador produce directamente
clases que encapsulan los resultados de la consulta. No hay datasets ni
datatables por ningún lado.

Finalmente cuando digo que el nombre de tabla se manda como string es con
la idea de armar un select en un string.
Algo parecido a: "select * from "+cNombreTabla+" where
PK="+nValorPK.ToString().Trim()

Sí, si. Eso se lo puedes meter al CommandText del SelectCommand de un
DataAdapter, con él haces un Fill de un DataTable, y devuelves el Rows[0]
de ese DataTable. Sobre ese DataRow devuelto (llamémosle Reg) ya puedes
preguntar por el Reg["TrFec"] y demás columnas, como querías.

[...Linq...]

Bien pero lo que hace es generar el codigo por mi no ? es decir crear un
dataset tipado y los datatables tipados , no es asi? Si lo es pues es
igual y lo quería evitar.

No, el Linq no funciona asi. El código de selección de datos lo tienes
que escribir tú, y lo que ocurre es que el compilador produce directamente
clases que encapsulan los resultados de la consulta. No hay datasets ni
datatables por ningún lado.

No se si es confusion pero yo baje la version beta del 2008 y veo que al
agregar una tabla a mis datasources en un form, ciertamente como dice Beto
automaticamente me genera todo el codigo que me genera VS2005, es decir
datasets, datatables, datacolumns, etc.

Se hacen consultas por Linq a una base de datos directamente sin tener que
agregar las tablas a los datasources?


Rafael