¿Debo preocuparme por la ruta de actualización para LINQ (el lenguaje de consulta)

Question

Estoy empezando a usar LINQ como un verdadero lenguaje de consulta en código para ayudar a mejorar la legibilidad. Hasta hace poco tenía miedo de tocar LINQ debido a que el equipo de LINQ to SQL se movió bajo el equipo de Entity Framework (tratando de ignorar esa conversación aquí): ¿LINQ el lenguaje de consulta será una apuesta segura en el futuro? industria móvil)?

Answer 1

Vale la pena distinguir entre " LINQ " y " un proveedor LINQ particular " ;. Creo que es seguro decir que LINQ está aquí para quedarse, y es fenomenalmente útil para el procesamiento de colecciones en proceso a través de LINQ to Objects.

En cuanto a qué proveedor de LINQ " win " (si corresponde): es una apuesta más difícil de igualar.

Sin embargo, ciertamente aprendería los fundamentos de LINQ, y LINQ to XML también es una API XML encantadora.

Answer 2

Como dijo Jon, es muy importante distinguir entre los proveedores de LINQ. Por ejemplo

• LINQ to objects: Esto se basa en IEnumerable < T > y está tan arraigado en el BCL que me resulta muy difícil que esto vaya a cualquier parte
• LINQ to SQL: No uso esto casi tanto como LINQ, pero sé que tiene un buen seguimiento y parece que a la gente le gusta.

Advertencia: trabajé en LINQ, así que soy bastante parcial aquí.

Lo que es realmente bueno de LINQ, en lo que creo que realmente acertamos, es que cualquiera puede escribir un proveedor de LINQ. Todo lo que se necesita son algunos métodos enlazables del nombre correcto y de repente tiene una sintaxis de consulta.

var query = from it in someCollection select it.SomeProperty;

Puedo escribir esta declaración sin usar ninguno de los 3.5 framework. Tengo mi propio proveedor LINQ que funciona en el marco 2.0 y es compatible con la sintaxis de consulta utilizada en el compilador

Personalmente, me inclino más por el método lambda / extensión synatx, pero el código resultante no es realmente diferente.