By juliana | April 22, 2008
According to DA GURU (that’s Scott Guthrie), on his article LINQ to SQL (Part 5 – Binding UI using the ASP:LinqDataSource Control)
We will also take advantage of the built-in paging/sorting support within LINQ to SQL to ensure that features like the product listing paging/sorting are performed not in the middle-tier, but rather in the database (meaning only 10 products are retrieved from the database at any given time – we are not retrieving thousands of rows and doing the sorting/paging within the web-server).
Whoohoo! Automatic server side paging. Srsly? Must read more and find a way to implement. Never mind that I’ve already done my stored procedures for the old way of doing server-side paging; this is worth the investment. (Even if some people don’t think so.)
Read the rest of the article here.
ETA: After digging through the articles, I’ve come to the conclusion that this automatic paging only works if you’re LINQ’ing directly to the database tables (e.g. using LINQ expression/syntax). The interface takes care of the iteration so that it only draws out the necessary rows. However, I believe if you’re using LINQ to access a stored procedure, you lose this automatic “skip and take” feature. At least, that’s what it seems to me. Throwing a SP into the DBML only exposes the SP interface, but LINQ would be able to go into the stored procedure and optimize it. So, in order to do paging by LINQ , the stored procedure would have to retrieve all the rows (think: virtual table, except this one has to be constructed completely and wholly every time it’s called) and hand it off the LINQ. Yeouch.