Linq to SQL: проекции, ViewModels, непереводимые запросы

Question

Моему приложению приходится работать с большими объемами данных, обычно выбранный размер составляет около 10000 строк. Для повышения производительности рекомендуется выбирать только необходимые данные.

Когда мне приходится выполнять расчеты или заниматься любым значимым делом, мне удобно выбирать все данные, чтобы правильно создать экземпляр моей модели, чтобы я мог положиться на ее функциональность.

При просмотре только данных (чаще всего в виде таблицы) это не то, что мне нужно, я хочу ограничить объем извлекаемых данных до абсолютного минимума.

До сих пор я использовал следующий подход для получения данных из моих репозиториев (ниже показан метод, который выполняет всю магию внутри репозитория:

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();
}

Таким образом, у меня есть определение типа для анонимного типа в методе, который вызывает хранилище, и я могу прозрачно работать с этим типом.

Каждый контроллер может точно определить, какие данные передать в представление, это очень эффективно, поскольку я могу напрямую влиять на порядок столбцов и т. д., не имея необходимости иметь дело с Grid Control в представлении, чтобы сделать это для меня. Мне не нужны никакие LoadOptions для DataContext, потому что это выясняется на основе селектора.

Теперь проблема в том, что я не могу управлять селектором, который передается в мой репозиторий. Он также может содержать вызовы методов и т. д., которые не могут быть переведены.

Мой вопрос:

<Ол>

До сих пор я избегал создавать ViewModels, потому что боюсь взрыва типа. Каков наилучший способ их реализации? Должен ли я сделать селекторы доступными для меня?

Должен ли я писать модульные тесты, которые ничего не проверяют, но выполняет ли запрос без исключения?

Answer 1

Я бы порекомендовал вам создать ViewModels, чтобы вы работали с известным набором классов, на самом деле Type Explosion не представляет особой проблемы, поскольку в любом случае вы в настоящее время используете анонимные типы, которыми, вероятно, немного сложнее управлять.

Если у вас (как правило) по одному ViewModel на View, он становится достаточно чистым. В некоторых случаях вы даже можете поделиться своими ViewModels, хотя я бы порекомендовал против этого, так как рано или поздно одному из потребителей понадобится больше данных / полей, а другому - раздутая ViewModel.