1-20 start/2007-02-28/1

Does this really makes sense? Shouldn't be the persistence framework a small set of operations and then you would create more complex operations - such as paging - around it? pabrantes

As we saw, the problem with that is the lack of control over the specific features of the DB that allow to improve performance.

From the LINQ documentation: The Standard Query Operators is an API that enables querying of any .NET array or collection.

I have only read a couple of lines but it looks like it's an in-memory query infrastructure that offers a language that is resembles SQL. So that does not solve our problem of a "transparently persisted OO model capable of offering efficient query with paging operations". I give a further look at

Regarding the previous example, jpmsi is right, those parameters in the pagedExecute method make sense but my goal was other. I was focusing on the problem stated before where, after the query, you would need to do extra computation in memory and redo part of the filtering already made in the DB. So the example shows a Page structure that would give you for each page a list of Item, for each Item the list of orders that matched the query for that item, for each order, the corresponding customer, and for each customer it's country. This information would be obtained with one query, possibly directly from the DB, and stored efficiently (uh, the magic word, but I was only thinking on lazy loading :-D) in the Page structure thus preventing us to reiterate over the Item's orders.