The result of a query
expression is never the same object as the source data, unless the LINQ provider has
been poorly coded. This can be important from a data integrity point of view??”a provider
can return a mutable result object, knowing that changes to the returned data
set won??™t affect the ???master??? even in the face of a degenerate query.
When other operations are involved, there??™s no need for the compiler to keep ???noop???
select clauses. For example, suppose we change the query expression in listing 11.7
to select the whole defect rather than just the name:
from bug in SampleData.AllDefects
where bug.Status != Status.Closed
where bug.AssignedTo == SampleData.Users.TesterTim
select bug
We now don??™t need the final call to Select, so the translated code is just this:
SampleData.AllDefects.Where (bug => bug.Status != Status.Closed)
.Where (bug => bug.AssignedTo == tim)
These rules rarely get in the way when you??™re writing query expressions, but they can
cause confusion if you decompile the code with a tool such as Reflector??”it can be surprising
to see the Select call go missing for no apparent reason.
With that knowledge in hand, let??™s improve our query so that we know what Tim
should work on next.
11.3.3 Ordering using an orderby clause
It??™s not uncommon for developers and testers to be asked to work on the most critical
defects before they tackle more trivial ones.
Pages:
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553