Вы ToList ()?

У нас есть тот же сценарий - связь WCF к серверу, сервер использует LINQtoSQL.

Мы используем.ToArray () при запросе объектов с сервера, потому что это "недопустимо" для клиента для изменения списка. (Значение, нет никакой цели поддерживать ".Add", ".Remove", и т.д.).

, В то время как все еще на сервере, однако, я рекомендовал бы оставить его, поскольку это - значение по умолчанию (который не является IEnumerable, а скорее IQueryable). Таким образом, если Вы хотите отфильтровать еще больше на основе некоторых критериев, фильтрация, ВСЕ ЕЩЕ на стороне SQL, пока не оценено.

Это - очень важный момент, поскольку это означает невероятное увеличение производительности или потери в зависимости от того, что Вы делаете.

ПРИМЕР:

// This is just an example... imagine this is on the server only. It's the
// basic method that gets the list of clients.
private IEnumerable<Client> GetClients()
{
    var result = MyDataContext.Clients;  

    return result.AsEnumerable();
}

// This method here is actually called by the user...
public Client[] GetClientsForLoggedInUser()
{
    var clients = GetClients().Where(client=> client.Owner == currentUser);

    return clients.ToArray();
}

Вы видите то, что происходит там? Метод "GetClients" собирается вызвать загрузку ВСЕХ 'клиентов' от базы данных... ТОГДА оператор Where, окажется, в методе GetClientsForLoogedInUser отфильтрует его.

Теперь, заметьте небольшое изменение:

private IQueryable<Client> GetClients()
{
    var result = MyDataContext.Clients;  

    return result.AsQueryable();
}

Теперь, фактической оценки не произойдет, пока ".ToArray" не называют..., и SQL сделает фильтрацию. НАМНОГО лучше!

В случае Linq к объектам, возвращаясь List<T> от функции не так хорошо как возврат IList<T>, как указывает ПОЧТЕННАЯ СТРЕЛЬБА ПО ТАРЕЛОЧКАМ. Но часто можно все еще добиться большего успеха, чем это. Если вещь, которую Вы возвращаете, должна быть неизменной, IList является плохим выбором, потому что это приглашает вызывающую сторону добавлять или удалять вещи.

, Например, иногда у Вас есть метод или свойство, которое возвращает результат запроса Linq или использует yield return для ленивой генерации списка, и затем Вы понимаете, что было бы лучше сделать это в первый раз, когда Вас звонят, кэшируете результат в List<T> и возвращаете кэшированную версию после этого. Именно тогда возврат IList может быть плохой идеей, потому что вызывающая сторона может изменить список в их собственных целях, которые тогда повредят Ваш кэш, делая их изменения видимыми во все другие вызывающие стороны.

Лучше для возврата IEnumerable<T>, таким образом, все они имеют, вперед повторение. И если вызывающая сторона хочет быстрый произвольный доступ, т.е. им жаль, что они не могли бы использовать [] для доступа индексом, они могут использовать ElementAt, который определяет Linq так, чтобы это бесшумно осуществило сниффинг для IList и использование, что при наличии, и если не это делает немой линейный поиск.

Одна вещь я использовал ToList для, когда у меня есть сложная система выражений Linq, смешанных с пользовательскими операторами, которые используют yield return, чтобы отфильтровать или преобразовать списки. Продвижение через в отладчик может стать могущественным сбивающий с толку, когда это переходит вокруг выполнения отложенных вычислений, таким образом, я иногда временно добавляю ToList () к нескольким местам так, чтобы я мог более легко следовать за путем выполнения. (Хотя, если вещи Вы выполняетесь, имеют побочные эффекты, это может изменить значение программы.)

Это зависит, если необходимо изменить набор. Мне нравится использовать Массив, когда я знаю, что никто не собирается добавить/удалить объекты. Я использую список, когда я должен отсортировать/добавить/удалить объекты. Но, обычно я просто оставляю его как IEnumerable, пока я могу.

Если Вам не нужны дополнительные функции List<>, почему не просто придерживаются IQueryable<>?!?!?! Наименьший общий знаменатель является лучшим решением (особенно, когда Вы видите ответ Timothy).