3 ms·
The example with lambdas should be written on multiple lines, too. At the same time, you can leverage the => syntax to avoid braces and end up with five lines:
by Kwpolska 1y ago
The example with lambdas should be written on multiple lines, too. At the same time, you can leverage the => syntax to avoid braces and end up with five lines:
List<Product> GetExclusiveProducts(List<Product> source)
=> source
.Where(p => p.ProductTitle == "iPhone")
.OrderBy(p => p.TypeOfPhone)
.ToList();
(You could join the first two lines, but I think that’s ugly for multi-line expressions.)
Also, less lines is not a good argument for SQL-style syntax vs method-call syntax. The good argument is that the SQL-style syntax is limited to only a few basic operations, when there are many more useful methods available.
Another reason is that this does not compile:
List<Product> GetExclusiveProducts(List<Product> source)
{
return from p in source
where p.ProductTitle == "iPhone"
orderby p.TypeOfPhone
select p;
}
This method returns IOrderedEnumerable<Product>, not a list. To fix it, you would need to either change the return type, or go outside of the SQL-style syntax and call the ToList method:
return (from ... select p).ToList();
- recursive 1y agoThere are some things that are harder to write in extension methods too. Such as `let` declarations. Or multiple from clauses referencing iterating variables from multiple levels. I use both.
- tracker1 1y agoI'm largely with you on this... I prefer the extension methods myself most of the time. Also adjacently worth mentioning that I tend to use Dapper instead of EF, so there's even less use of this type of expression all around unless it's actual SQL or assembled SQL via a query builder.