views:

56

answers:

1

Dear All!

In my ASP.NET web-application I use NHibernate to persist my "User"-Instances, where each of them has a "Entries" - collection. It is a typical one-to-many mapping and it works just fine. The mapping-code for the entries looks like this:

<bag name="Entries" cascade="all-delete-orphan">
   <key column="UserID" />
   <one-to-many class="MyApp.Entities.Entry, MyApp.Entities" />
</bag>

Now I have a page, where I want to display a grid with all the entries of the logged-in user. To do so, I could simply bind the "Entries" property of the current user to the Grids "DataSource" - property. This also works just fine, but this also means, that the grids built-in paging-functionality (Telerik RadGrid) doesn't have any effect on database-performance, because all the entries will be loaded each time when displaying the grid.

Therefore I could apply my custom-paging, where I only fetch the rows which I need to display the grids current page. A typical Linq2NHibernate query looks like this:

var query = from entry in Session.Linq<Entry>()
                    where entry.User == currentUser
                    select entry;
query.Skip(pageNum * pageSize).Take(pageSize).ToList();

Using this approach I need to extend my repository altough NHibernate has already done the mapping between User and Entry...

My question is: If I use LINQ to directly query the "Entries"-collection of my "User"-object - does this mean, that all the Entries will be loaded from the database and then filtered in memory or would this be translated to a real "database"-query, so that I could use this much more comfortable approach to implement paging?

Example:

myGrid.DataSource = currentUser.Entries.Skip(pageNum * pageSize).Take(pageSize).ToList();

J4I: Of course I use lazy-loading in the mapping files...

Thank you in advance!

A: 

LINQ on the collection will always be LINQ-to-objects, as they don't implement IQueryable, so you'd be loading everything in memory.

A query is the only possible approach at this moment.

Diego Mijelshon
@Diego - will this still be the case with the NH3 linq provider?
DanP
Yes, the provider sits on top of the query engine; collection management hasn't changed. You can do LINQ queries on entity collections, but not directly on retrieved objects.
Diego Mijelshon
@Diego - thanks for the confirmation..that's a bit of a bummer as this would make linq usage far more coherent. I'm guessing that this would cause problems with dirty-tracking in collections, etc though; right?
DanP
I think it's something that *can* be implemented, but there are several design challenges to overcome.
Diego Mijelshon