Respuestas a preguntas sobre LINQ en el Developer's Day
Haciendo eco del post de David Salgado, reproduzco aquí las respuestas a las preguntas sobre LINQ recibidas por SMS durante el pasado Developer's Day. Me he permitido unas ligeras adiciones, siempre que revisa al cabo de un tiempo lo que se ha escrito se encuentran maneras de mejorarlo :-)
1. No entiendo porqué la select está al final en LINQ ¿porqué no respeta la sintaxis SQL?
Piensa en la sentencia SELECT de SQL, por ejemplo:
// candidatas para David Sal(Del)gado
SELECT Nombre, Apellidos
FROM Amigos
WHERE Sexo = ‘M’ AND EstadoCivil = ‘S’ AND Edad <= 25
Después de teclear SELECT, el entorno de desarrollo no podrá darte ayuda de ningún tipo con relación a los campos que quieres seleccionar, porque aún no sabe con qué tabla(s) vas a trabajar (lo cual se indica en la cláusula FROM).
Con la sintaxis que propone LINQ:
from f in db.Amigos
where f.Sexo == ‘M’ and f.EstadoCivil = ‘S’ and f.Edad <= 25
select new { f.Nombre, f.Apellidos };
se resuelve ese problema. Cuando tecleas 'f.' detrás del where, ya el entorno sabe que f es de tipo Amigo, porque db.Amigos es de tipo Table<Amigo> (que implementa IEnumerable<Amigo>).
Esta decisión ha sido motivo de amplias discusiones (no violentas :-) dentro de los equipos de desarrollo de MS. De hecho, en la Presentación Preliminar de Mayo de 2006, en VB.NET el Select se ponía delante. Ahora ambos lenguajes utilizan el Select al final.
2. ¿Qué es eso del var en C# 3.0? ¿Acaso el lenguaje va a dejar de ser estáticamente tipado?
La sentencia var en C# 3.0 hará que el compilador infiera o deduzca el tipo de la variable en función del tipo de la expresión que se coloque del lado derecho de la asignación (var solo se podrá utilizar junto con una expresión de inicialización). Por ejemplo, en:
var s = “Hola”;
el compilador determinará que el tipo de la variable s es string. No es object, ni Variant como en VB6, ni una variable “amorfa” como en Javascript, ni nada por el estilo. La aparición de var no implica que C# deje de ser un lenguaje con fuerte control de tipos ni mucho menos. Simplemente el lenguaje nos facilita la vida, no obligándonos a indicar el tipo de la variable y encargándose él de deducirlo. En principio, el uso de var solo es imprescindible cuando la expresión a la derecha de la asignación es de un tipo anónimo (otra nueva característica de C# 3.0).
Por supuesto, esta característica debe usarse juiciosamente, porque su uso indiscriminado puede llevar a que nuestro código se haga menos legible.
3. Si no sabes el tipo de algo, ¿cómo sabes con qué propiedades y métodos lo manejas?
Esta pregunta tiene relación con la anterior. Dado que C# es un lenguaje estáticamente tipado, el compilador (y el entorno, que se apoya en él) siempre sabe el tipo de cualquier variable o expresión, ya sea porque se lo decimos nosotros o porque él lo deduce (como ocurre cuando usamos var para declarar una variable). Suponiendo que hemos definido la variable ‘s’ de la pregunta anterior, cuando tecleemos ‘s.’ dentro del editor nos aparecerá la lista de propiedades, métodos y eventos de la clase string. Y si se trata de una variable de un tipo anónimo (generado internamente por el compilador), la ayuda Intellisense nos dirá qué propiedades, métodos y eventos tenemos a nuestra disposición.
4. ¿Qué rendimiento presenta LINQ respecto a la consulta directa usando el DOM para XML o sentencias SQL para BBDD?
Aunque no he hecho pruebas de rendimiento específicas, pienso que el rendimiento de LINQ to XML (por ejemplo, en búsquedas XPath) debe ser muy cercano al que podemos obtener hoy con el DOM. En el caso de LINQ to SQL, la diferencia podría ser algo mayor. Yo y otros compañeros hemos detectado en ocasiones que las sentencias SQL generadas por LINQ to SQL (se puede utilizar la propiedad Log del objeto de conexión para enviar las sentencias a la consola o un fichero y así poder examinarlas) son menos eficientes de lo que podría obtenerse escribiendo la sentencia “a mano”. Esto es lo que ocurre casi siempre que dejamos de hacer algo manualmente y comenzamos a apoyarnos en una herramienta automática. En defensa de LINQ to SQL hay que decir que:
a) Estamos trabajando aún con una versión pre-beta, que sin lugar a dudas mejorará mucho antes de la salida del producto final.
b) En cualquier caso, se seguirá investigando a ese respecto para futuras versionesJ.
c) El contexto de datos tiene una propiedad Connection que da acceso a la conexión ADO.NET subyacente, a la que podremos recurrir en caso de que necesitemos obtener un rendimiento superior al que nos dé LINQ to SQL.
Como en todo, es cuestión de sopesar las ventajas contra los inconvenientes de una tecnología, y ver si es conveniente o no utilizarla. Para mí personalmente las ventajas (mayor expresividad y claridad del lenguaje, verificación del código en tiempo de compilación - al no tener que escribir las sentencias SQL como cadenas dentro de la aplicación-, ayuda Intellisense para las consultas integradas, mayor potencia en las API de actualización, etc.) superan a los inconvenientes en la mayoría de las situaciones en las que me encuentro habitualmente durante mi trabajo.
5. Ahora mismo tengo un AMD 3200+ con 1gb de RAM y vs05 corre a tirones ¿qué necesitaré para ORCAS?
Para que funcione la CTP de marzo, la página de descarga recomienda un Pentium III+ con 1 GB de memoria libre (lo que queda después de la carga del sistema operativo y los servicios). Mi experiencia personal me dice que 2 MB es lo óptimo. Los requisitos finales que se necesitará para ejecutar la versión definitiva de Orcas deberán ser algo menores.
En cualquier caso, no está de más repetir la recomendación de siempre: ¡no instalar esta CTP en un PC de trabajo!
6. ¿Hay LINQ to AS400?
La versión final de Orcas incorporará únicamente proveedores de LINQ to SQL para SQL Server 2000 y 2005. No obstante, ya hay otros fabricantes trabajando muy cerca de Microsoft para producir los correspondientes proveedores (no tengo la menor idea de si IBM está entre ellos).
Navegando por la red, hoy he encontrado este artículo en el que se habla de un gran interés de IBM hacia LINQ (y un cierto desinterés por parte de Oracle):
Redmond Developer News
7. ¿Mejora Windows Mobile con Orcas?
Windows Mobile 6 incorporará múltiples ventajas con respecto a la versión actual, aunque todo parece indicar que los desarrolladores no seremos los más beneficiados. La principal ventaja será que .NET CF vendrá incorporado ya en ROM, como puede leerse en la entrevista al Product Manager de Windows Mobile 6, en la dotNetManía de este mes (www.dotnetmania.com)