Стоимость выполнения пользовательской функции LinqToSql в запросе

Question

В моем приложении мне нужно отобразить некоторую информацию о клиентах (у клиента есть код и имя). Одним из полей является «отображаемое имя», где

DisplayName = Code + " - " + Name

Я извлекаю клиента из базы данных в модель представления и задаю DisplayName, например:

from   customer in this.Context.Customers
select new CustomerViewModel
       {
           DisplayName = customer.Code + " - " + customer.Name
       }

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

Поэтому я создал эту функцию

Func<Customer, string> CustomerDisplayName = (c => c.Code + " - " + c.Name)

и используйте его так:

from   customer in this.Context.Customers
select new CustomerViewModel
       {
           DisplayName = CustomerDisplayName(customer)
       }

Он работает нормально и делает логику многократно используемой, но проблема в том, что функция не может быть проанализирована в операторе SQL, поэтому LinqToSql сначала получает данные («Код» и «Имя»), а затем выполняет функцию для каждой записи.

Должен ли я беспокоиться о производительности (если у меня много данных) и придерживаться первого варианта? Или можно использовать функцию?

Answer 1

В вашей модели у вас есть класс Customer, который является частичным классом (см. Файл yourDataClasses.designer.cs).

Итак, вам нужно всего лишь изменить файл yourDataClases.cs, добавив частичныйКласс Customer и добавление к нему свойства DisplayName.

Ваш код в yourDataClases.cs выглядит так:

public partial class Customer
{
   public int DisplayName
   {
      get
      {
         return this.Code + " - " + this.Name;
      }
   }
}

Ваши запросы будут в порядке:

var res = from c in this.Context.Customers select c;

Answer 2

Вы извлекаете не только Код и Имя, но и всю сущность Клиента со всеми ее данными. Это будет медленнее. В зависимости от того, сколько данных на самом деле (сколько строк?), Это может или не может иметь значение с точки зрения производительности. Вероятно, это не так, если у вас меньше 1000 строк.

Получение большего количества столбцов может помешать SQL Server использовать индекс покрытия, поэтому с этой точки зрения он может быть намного медленнее. Если у вас в любом случае нет такого индекса, разница только в передаче по сети, что не так дорого.