Expresión fluida y de consulta - ¿Hay algún beneficio(s) de uno sobre otro?

Prefiero usar esta última (a veces llamada "sintaxis de comprensión de consulta") cuando puedo escribir toda la expresión de esa manera.

var titlesQuery = from e in entries
                  where e.Approved
                  orderby e.Rating
                  select e.Titles;

var title = titlesQuery.FirstOrDefault();

Tan pronto como tenga que agregar (paréntesis) y .MethodCalls(), cambio.

Cuando uso el primero, suelo poner una cláusula por línea, así:

var title = entries
    .Where (e => e.Approved)
    .OrderBy (e => e.Rating)
    .Select (e => e.Title)
    .FirstOrDefault();

Me parece un poco más fácil de leer.

Cada estilo tiene sus pros y sus contras. La sintaxis de consulta es más agradable cuando se trata de uniones y tiene la útil palabra clave let que facilita la creación de variables temporales dentro de una consulta.

La sintaxis fluida, por otro lado, tiene muchos más métodos y operaciones que no se exponen a través de la sintaxis de consulta. También, ya que son solo métodos de extensión, puede escribir el suyo propio.

He encontrado que cada vez que empiezo a escribir una instrucción LINQ usando la sintaxis de consulta termino teniendo para ponerlo entre paréntesis y volver a usar métodos de extensión LINQ fluido. La sintaxis de consulta simplemente no tiene suficientes características para usar por sí misma.

En VB.NET prefiero mucho la sintaxis de consulta.

Odio repetir lo feo Function-palabra clave:

Dim fullNames = { "Anne Williams", "John Fred Smith", "Sue Green" };
Dim query =
     fullNames.SelectMany(Function(fName) fName.Split().
     Select(Function(Name) New With {Name, fName})).
     OrderBy(Function(x) x.fName).
     ThenBy(Function(x) x.Name).
     Select(Function(x) x.Name & " came from " & x.fName)

Esta consulta ordenada es mucho más legible y mantenible en mi opinión:

query = From fullName In fullNames
        From name In fullName.Split()
        Order By fullName, name
        Select name & " came from " & fullName

VB.NET la sintaxis de consulta también es más potente y menos detallada que en C#: https://stackoverflow.com/a/6515130/284240

Por ejemplo, esta consulta LINQ to DataSet (Objects)

VB.NET:

Dim first10Rows = From r In dataTable1 Take 10

C#:

var first10Rows = (from r in dataTable1.AsEnumerable() 
                   select r)
                   .Take(10);

No obtengo la sintaxis de consulta en absoluto. No hay razón para ello en mi mente. que se puede llegar con .Seleccionar y tipos anónimos. Creo que las cosas se ven mucho más organizadas con la "puntuación".

La interfaz fluida si solo hay un dónde. Si necesito un select or orderby, generalmente uso la sintaxis de Consulta.

La sintaxis fluida parece más poderosa de hecho, también debería funcionar mejor para organizar el código en pequeños métodos reutilizables.

Sé que esta pregunta está etiquetada con C#, pero la sintaxis fluida es dolorosamente detallada con VB.NET.

Me gusta mucho la sintaxis Fluida y trato de usarla donde puedo, pero en ciertos casos, por ejemplo, cuando uso joins, generalmente prefiero la sintaxis de Consulta, en esos casos me resulta más fácil de leer, y creo que algunas personas están más familiarizadas con la sintaxis de Consulta (similar a SQL), que con lambdas.

Si bien entiendo y me gusta el formato fluido , me he atenido a la consulta por el momento por razones de legibilidad. La gente que acaba de ser presentada a LINQ encontrará Consulta mucho más cómodo de leer.

Prefiero la sintaxis de consulta ya que provengo de la programación web tradicional usando SQL. Es mucho más fácil para mí envolver mi cabeza alrededor. Sin embargo, creo que voy a empezar a utilizar el .Donde (lambda) ya que es definitivamente mucho más corto.

He estado usando Linq durante aproximadamente 6 meses. Cuando empecé a usarlo preferí la sintaxis de consulta, ya que es muy similar a T-SQL.

Pero, poco a poco me estoy acercando a lo primero ahora, ya que es fácil escribir trozos reutilizables de código como métodos de extensión y simplemente encadenarlos. Aunque encuentro que poner cada cláusula en su propia línea ayuda mucho con la legibilidad.

Acabo de configurar los estándares de nuestra empresa y hacemos cumplir el uso de los métodos de extensión. Creo que es una buena idea elegir uno sobre el otro y no mezclarlos en código. Los métodos de extensión se leen más como el otro código.

La sintaxis de comprensión no tiene todos los operadores y usar paréntesis alrededor de la consulta y agregar métodos de extensión después de todo me ruega por usar métodos de extensión desde el principio.

Pero en su mayor parte es solo preferencia personal con algunas excepciones.