LINQ

Hola Alfredo!

Ya lo había visto y no estoy nada de acuerdo en que solo sea "azucar
sintáctico".

Ahí solo digo que azúcar sintáctico es la sintaxis de expresiones de
consulta,
ya que se traduce mecánicamente en una secuencia de llamadas a métodos.
¿No?

La utilidad de consultar archivos XML creo que es muy pequeña, y LINQ
to Objects está implementado de una forma tan ingenua que sirve para
poco por lo lento que es. Y creo que no lo van a tener nada fácil para
optimizarlo.

Ja, no te adelantes a mi próximo post, que va sobre "la obsesión por el
rendimiento" :-)

He estado leyendo tu excelente libro sobre LINQ estos días y me ha
parecido entender que LINQ to SQL necesita que se generen clases para
corresponder a cada tabla. ¿Es eso así?

No necesariamente. Puedes usar

DataContext.ExecuteQuery<T>(string sentenciaSQL)

para ejecutar CUALQUIER consulta. Pero sí deberás definir ese tipo T, el
tipo del
resultado, que el compilador no puede determinar porque no sabe SQL.

En general, creo que para el trabajo práctico, las clases deben existir. O
bien dejas
que las genere automáticamente una herramienta (la de línea de comandos o el
asistente visual, que llama a aquella), o las escribes tú en C#/VB y las
marcas como
"clases de entidad" mediante atributos.

Saludos - Octavio

Hola Alfredo

He estado leyendo tu excelente libro sobre LINQ estos días y me ha
parecido entender que LINQ to SQL necesita que se generen clases para
corresponder a cada tabla. ¿Es eso así?

Claro que es asi, vamos que en cuanto a eso es casi igual que los datasets
tipados de siempre. Hasta usando ExecuteQuery<Tipo> hay que tener el 'Tipo'
previamente definido. La estricta necesidad de tener todos los tipos en
tiempo de compilacion es lo que le quita flexibilidad al linq to sql (otros
dirian que hasta al .NET en general).
Quiza la ventaja esté ahora en que se auto-generen menos lineas de codigo
que con los datasets :)
Debemos seguir investigando pero yo hasta ahora no le veo gran ventaja al
Linq to Sql; será que tal vez me sea mas util para manejar objetos (Linq to
objects) que para bases de datos.

Alberto

Claro que es asi, vamos que en cuanto a eso es casi igual que los datasets
tipados de siempre. Hasta usando ExecuteQuery<Tipo> hay que tener el
'Tipo' previamente definido. La estricta necesidad de tener todos los
tipos en tiempo de compilacion es lo que le quita flexibilidad al linq to
sql (otros dirian que hasta al .NET en general).

Mmmm... a ver si entiendo:

Si yo hago:
ExecuteQuery<Tipo>("Select fecha, codigo from BD1.dbo.Tabla")
Eso no me crea la clase resultante Tipo en runtime ????!!!!! Pues pensaba
que sí :(

O sea que para los fines el programa y la BD siguen siendo dos totalmente
desconocidos :) ya que todo hay que definirlo en en tiempo de compilacion.
Imagino que si uno amplia una longitud de campo char(N) en una tabla eso
implicaría tener que recompilar los fuentes y reemplazarlos en las PC's
(hablo de una aplicacion Windows).
Si estoy equivocado favor aclararmelo.

JL

Hola a todos,

Hasta usando ExecuteQuery<Tipo> hay que tener el 'Tipo' previamente
definido. La estricta necesidad de tener todos los tipos en tiempo de
compilacion es lo que le quita flexibilidad al linq to sql (otros dirian
que hasta al .NET en general).

Yo pienso que igual eso podría cambiar en el futuro, ahora que se han
añadido al lenguaje los tipos anónimos...

Slds - Octavio