Linq to SQL: проекции, ViewModels, непереводимые запросы - PullRequest
1 голос
/ 11 сентября 2009

Мое приложение имеет дело с большими объемами данных, обычно выбранный размер составляет около 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, потому что это выясняется на основе селектора.

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

Мой вопрос:

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

1 Ответ

1 голос
/ 11 сентября 2009

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

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

...