Error converting IEnumerable to List

[Solarion]

Thanks Roi! I will check this out in the morning, brain is a bit fried been at it all day

 

[Kosmik]

Sure... but its worth it, as its benefits outweigh any perceived obfuscation cost by...

• making code declarative; focusing more on what you want to achieve as opposed to being bog down with technicalities of how it's achieved.
• using laziness to make it easier to avoid Big O compute costs for complex transformations

It does. Personally I use lambdas more than straight linq, any heavy cross querying I leave down in the db level for optimized crunching but I'm talking from a web perspective where you really don't want any processing overhead on that side. Application domains may be very different, can't talk from much experience there although I'd probably still apply the basic ethos of "if its database intensive, do it there!".

 

[[)roi(]]

It does. Personally I use lambdas more than straight linq, any heavy cross querying I leave down in the db level for optimized crunching but I'm talking from a web perspective where you really don't want any processing overhead on that side. Application domains may be very different, can't talk from much experience there although I'd probably still apply the basic ethos of "if its database intensive, do it there!".

Not sure I get what you differentiate as lambdas versus straight Linq? An example of either would help with clarity.

As for processing overhead; not sure why you would regard Linq as having an extra processing overhead; IMO it's performant irrespective of domain; re DB aspect I agree; Linq shouldn't be used for something that could be optimized at the DB.

 

[Kosmik]

Not sure I get what you differentiate as lambdas versus straight Linq? An example of either would help with clarity.

As for processing overhead; not sure why you would regard Linq as having an extra processing overhead; IMO it's performant irrespective of domain; re DB aspect I agree; Linq shouldn't be used for something that could be optimized at the DB.

Basic linq :

from e in employees
where e.branchID==8
select e

vs

employees.find(e=>e.branchID==8)

Something like that, not sure offhand of syntax. I recall when Linq was first introduced there was some form of overhead ( minimal ), can't exactly remember what but also that when compiled, it basically was a "wrapped" normal loop. Some folks had the mentality that it was necessarily quicker than a declared loop structure in execution just because it took less lines of code when it reality it compiled to the same was my understanding. As you said, its syntactically neater and better for code readability and maintenance. I wasn't differentiating so much as saying my preference for use of the lambdas and predicates for quick collection queries.

Ah and my overhead comment was related to bringing data to a client program and crunching information on there rather than preparing it on a db level ( not linq itself ). Came across quite a bit of code where folks went Linq mad and did everything at either a BL layer where it would have been better to prep the data on the db and then pass those results for processing.

 

[[)roi(]]

Basic linq :

from e in employees
where e.branchID==8
select e

vs

employees.find(e=>e.branchID==8)

Something like that, not sure offhand of syntax. I recall when Linq was first introduced there was some form of overhead ( minimal ), can't exactly remember what but also that when compiled, it basically was a "wrapped" normal loop. Some folks had the mentality that it was necessarily quicker than a declared loop structure in execution just because it took less lines of code when it reality it compiled to the same was my understanding. As you said, its syntactically neater and better for code readability and maintenance. I wasn't differentiating so much as saying my preference for use of the lambdas and predicates for quick collection queries.

.Find originates from .NET 2.0 when List was introduced.
The Linq equivalent Linq extension method is .Where -- basically all three of these have essentially the same computation profile.

employees.find(e=>e.branchID==8)

employees.Where(e=>e.branchID==8)

from e in employees
where e.branchID==8
select e

The only difference with Linq is that the underlying code is Lazy; meaning the Where or any other chained Linq method calls won't be computed until you use a method like ToList, ToArray, etc.

The benefit is that for multiple chained Linq method calls; the computation cost remains linear; it achieves this through composition of the underlying computations e.g. using a single loop that filters and transforms the data at the same time.

The other benefit with Linq query syntax (from e in ...) is that you can create Linq extensions methods for your own types e.g. I use it for my custom data types like Maybe, Either, Result, ...
Example of a custom Linq Select extension method; the same can be created for SelectMany, Where, etc. BTW Once you've defined these Linq extension methods for your type; it will work seamlessly with the Linq Query syntax (from e in ...)

Ah and my overhead comment was related to bringing data to a client program and crunching information on there rather than preparing it on a db level ( not linq itself ). Came across quite a bit of code where folks went Linq mad and did everything at either a BL layer where it would have been better to prep the data on the db and then pass those results for processing.

Suspect that might have been Linq2SQL; which allowed direct DB queries without the need for SQL or stored procedures. This was done away with because of both performance issues and for the fact that Microsoft decided to focus on its Entity Framework instead.

Btw Linq for collection types like List never suffered from those kind of performance issues.