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)


 

Octavio Hernandez

Desarrollador y consultor en tecnologías .NET. Microsoft C# MVP entre 2004 y 2010.

2 comentarios en “Respuestas a preguntas sobre LINQ en el Developer’s Day

  1. Magistrales, como siempre, tus respuestas a estas cuestiones. Pero me queda alguna laguna con respecto al tipo var.

    Entiendo perfectamente que el compilador define el tipo de la variable en funcion del tipo retornado por la expresión. Ya que cualquier expresión o llamada a metodo siempre retorna un tipo concreto. Pero me queda en el aire lo siguiente.

    – ¿No crees que la existencia de este tipo lleve a programadores poco disciplinados a subreutilizarla creando codigo poco legible?.

    – Supongo que el echo de que el compilador tenga que decidir el tipo de la variable tenga una panalización. Mi duda es, esta “decisión” la toma el compilador que genera el codigo IL o bien el framework. Lo digo porque lo segundo afectaria al rendimiento de la aplicación, lo primero, solamente a los tiempos de compilación.

    – ¿Puedes hablar un poco mas del tipo anónimo?. Cual es su proposito, como se usa, en que casos y porque existe.

    Muchas gracias.
    Fidel

  2. Hola, Fidel!

    Respondo a tus preguntas:

    a) Sí, en principio ese peligro existe, creo. Algún que otro “avispado” podría empezar a utilizar “var” en todas sus declaraciones, lo cual podría reducir la legibilidad del código. La palabra clave, creo, es EDUCACION. Educar al programador a utilizar var solo en los casos en que es imprescindible (cuando la consulta devuelve IEnumerable y cuando se va a iterar con foreach sobre ella. Puede que haya otros casos en los q sea útil.

    b) La decisión siempre la toma el compilador – no se afecta el rendiimiento para nada.

    c)Los tipos anónimos son tipos generados por el compilador como resultado de la ejecución de una consulta. Por ejemplo, la consulta:

    from f in db.Amigos
    where f.Sexo == ‘M’ and f.Edad <= 25 select new { f.Nombre, f.Apellidos }; produce una secuencia de objetos de un tipo anónimo (bueno, realmente el tipo tiene un nombre, generado automáticamente, que puede ser "Amigos$T01" o algo por ese estilo; solo que tú como programador no puedes referirte a él) que tiene solo dos propiedades: Nombre y Apellidos. En este caso, el uso de var tanto para asignar el resultado de la consulta como para recorrerla es imprescindible: var chicas = from f in db.Amigos where f.Sexo == ‘M’ and f.Edad <= 25 select new { f.Nombre, f.Apellidos }; foreach(var ch in chicas) Console.WriteLine(ch.Nombre); Slds - Octavio

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *