Can I (and should I) force NHibernate future queries to execute at a certain point?

Question

I'm using NHibernate future queries in an MVC 3 web application, and trying to keep all my database access happening in my controllers, and not in my views. The site is a catalog of Resources (descriptive blurbs), which have a many-to-many collection of Grades, and a many-to-many collection of Topics. Users select one or more grades, and one or more topics, and then get a list of matching resources.

In order to populate the search form, I'm using future queries to get all the grades and topics:

    public Domain.SearchFormData GetSearchFormData()
    {
        // Get all grades and all topics using a multiquery.

        IEnumerable<Grade> grades = Session.QueryOver<Grade>()
            .Future();

        IEnumerable<Topic> topics = Session.QueryOver<Topic>()
            .Future();

        var result = new SearchFormData();
        result.Grades = grades;
        result.Topics = topics;
        return result;
    }

This is very simple and works fine, and returns a SearchFormData, which is a simple DTO. This query is executed in the controller, and the result doesn't need any further processing, so it's passed right into the view for rendering as lists of checkboxes.

But because of the lazy execution of future queries, the database access isn't triggered until the view starts iterating the lists. This is considered by some (like NHibernate Profiler) to be a no-no, and they say that by the time the view starts rendering, all of the database access should be done. The principal reason is that it's easy to have a hidden SELECT N+1 going on if you don't.

Here that doesn't apply; both grade and topic are simple objects without collections. I don't mind too much that the view will trigger database access. But it's making me look for a clean, clear, way to trigger all the future queries. One way to do it is to access the results, like by copying the IEnumerable into a list. But that's not really something I need to do; I just want to execute the queued up queries.

I think it makes sense for the trigger to happen outside the query above. I might need other data to render the full page view, and I might be using other future queries to get it. For example, the home page might also show the five most popular resources and the total number of resources. Then the controller would be invoking multiple methods to accumulate what it needs for the view, and it would be most efficient to execute all of them at once. Of course one way to do that is to expand my GetSearchFormData into GetAllHomePageData and return a DTO with fields for everything on the home page. But I use the search form all over, not just on the home page. So I'd be losing some nice modularity that way.

Answer 1

The following approach needs a bit of polish, but here it is anyway. I hope it's useful to somebody. I may come back later and clean it up.

For LINQ, HQL, and SQL Query futures, use:

public static void ExecuteFutureQueries(this ISession session)
{
    var sessionImpl = (ISessionImplementor) session;
    var dummy = sessionImpl.FutureQueryBatch.Results;
}

For QueryOver and ICriteria futures, use:

public static void ExecuteFutureCriteria(this ISession session)
{
    var sessionImpl = (ISessionImplementor) session;
    var dummy = sessionImpl.FutureCriteriaBatch.Results;
}

Be careful, though. Calling this method when there are no future queries of that type will result in an exception being thrown.