Linq to SQL: Projections, ViewModels, non translatable queries

Question

My application has to deal with large amounts of data, usual select size is about 10000 rows. In order to improve performance it is recommended only to select the data needed.

When i have to do calculations or any meaningful business i am comfortable with selecting all the data in order to instantiate my model correctly so i can rely on its functionality.

When only viewing data (most often in a table) this is not what i want, i want to limit the amount of data retrieved to the absolute minimum.

So far i've used the following approach to get data from my repositories (shown below is the method that does all the magic inside the repository:

private IEnumerable<TResult> GetAllProject<TResult>(Expression<Func<T, TResult>> selector, Expression<Func<T, bool>> predicate)
{
    SetReadContext();
    var query = DataContex.Table<Order>().Where(predicate).Select(selector);

    return query.ToList();
}

That way i have the type definition for the annonymous type in the method that invokes the repository and i can transparently work with the type there.

Every controller can define exactly what data to pass to the view, it is very efficient as i can directly influence column ordering etc. without having to deal with the Grid Control in the View to do that for me. I don't need any LoadOptions on the DataContext because it figures that out based on the selector.

The problem is now, that i dont have control the selector that is passed to my Repository.It may aswell contain method invocations etc. that are not translatable.

My question is:

1. Thus far, i have avoided to create ViewModels because i fear type explosion. What is the best way to implement them? Should i make selectors available that do the projecting for me?
2. Should i write unit tests that do check nothing but if the query executes without exception?

Answer 1

I would recommend you create ViewModels so you're working with a known set of classes, Type Explosion isn't really a concern, since you're currently using anonymous types anyway, which are probably a bit harder to manage.

If you (usually) have a single ViewModel per View then it becomes resonably clean. In some cases you can even share your ViewModels, although I would recommend against it since sooner or later one of the consumers ends up needing more data/fields and the other ends up with a bloated ViewModel.