Readability is the main issue here. Consider that
Table.AsEnumerable().Where(somePredicate)
is far more readable than
((IEnumerable<TableObject>)Table).Where(somePredicate).
Or imagine wanting to execute part of the query on the SQL Server and the rest in memory:
Table.Where(somePredicate)
.Select(someProjection)
.AsEnumerable()
.SomethingElse()
versus
((IEnumerable<SomeProjectionType>)Table.Where(somePredicate)
.Select(someProjection))
.SomethingElse()
Now, as for why such a method is useful at all think of the example of a Table
in a LINQ to SQL DataContext
. As Table
is an IQueryable
it implements IEnumerable
. When you invoke a Where
method on such a Table
and enumerate through the results, code is executed that eventually causes a SQL statement to be executed on a SQL Server. What AsEnumerable
does is says, no, I don't want to use the LINQ to SQL provider to execute the Where
, I want to use the LINQ to Objects implementation of Where
.
Thus enumerating over
Table.Where(somePredicate)
causes a query to be executed on a SQL Server whereas enumerating over
Table.AsEnumerable().Where(somePredicate)
brings the table represented by Table
into memory and executes the Where
functionality in memory (and not on the SQL Server!)
This is the point of AsEnumerable
: to allow you to hide a specific implementation of IEnumerable
methods and instead use the standard implementation.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…