Каждый C#-разработчик хотя бы раз писал что-то вроде:
var result = numbers.Where(x => x > 10).Select(x => x * 2).Take(5);И почти каждый на старте карьеры удивлялся, узнав, что эта строчка ничего не вычисляет. Ни один элемент коллекции ещё не тронут, ни один предикат не вызван — вся цепочка спит. Вычисления начнутся только тогда, когда мы начнём перебирать result в foreach или вызовем .ToList().
Сравнивая различный code-style в проектах, я упоминал про методы проверки коллекций на наличие элементов. Самые очевидные способы – это использование LINQ-метода Any() или сравнение свойства Count с нулем. И если вы выбрали первый вариант, то могут быть проблемы с производительностью. Поэтому предлагаю подробнее рассмотреть этот вопрос. Кстати, если вы выбрали второй вариант, то проблемы так же могут быть.
Начнем с самого простого, с массива. Проверим, есть ли какая-то разница между вызовами array.Any() и array.Length != 0.
Краткое описание основных методов LINQ простым языком, без терминов "проекция", "предикат", "делегат" и проч. От термина "лямбда-выражение" избавиться не удалось :)
LINQ (Language Integrated Query) – это набор методов для работы с коллекциями.
Для простоты здесь будем называть коллекцией любой объект, который хранит несколько других объектов. Это может быть массив из чисел, или результат запроса к базе данных, или набор элементов, прочитанных из документа XML и т.д.
Методы LINQ вызываются в исходном коде, как и другие методы, пример на языке C#:
var result = nums.Select( n => n*2 );Дисклеймер: В статье рассматриваются только Query (аналог GET-запросов). Мутации и подписки не рассматриваются.
GraphQL - это инструмент, позволяющий заменить привычное API. Вместо написания контроллеров и методов, вы пишете методы в Query:
public class GraphQLQuery
{
public IQueryable<UserModel> GetUsers([Service] IUsersRepository repository)
{
return repository.Users;
}
}Всего пару строк и вы добавили в приложение новый GraphQL-endpoint. Теперь к нему можно обратиться POST-запросом (обычно), передав вот такую строку:
users {
id
userName
roles {
code
description
}
}
Исторически так сложилось, что LINQ взыскал сомнительную репутацию за его слабую производительность. LINQ медленный, аллоцирует память, сложно читается, поэтому обычно его используют как инструмент запросов к БД и то, зачастую сложные запросы легче написать на SQL. Даже на собеседованиях джунов просят не использовать LINQ в алгоритмах.
Кому не нравится LINQ в C#? Встроенная и уже достаточно старая фича языка C# и рантайма .NET.
Но можем ли мы сделать более эффективную версию этой фичи?
Можем сделать более эффективную, но намного менее универсальную. Github проекта.
Можете ли вы уверенно сказать, что будет выведено на консоль в результате выполнения следующего кода?
Если вы ответили восемь, то, скорее всего, эта заметка не для вас, остальным же предлагаю отправиться вместе со мной в небольшое путешествие в волшебную страну .Net и поближе взглянуть на ее "магию".
Как же получилось 8? Основное удивление может нас постигнуть, если мы попробуем приоткрыть завесу тайны в отладчике:
Привет. В этом очерке расскажу, как я реализовывал компиляцию математических (численных и логических) выражений в делегат при помощи Linq Expression.
Навигация: Проблема · Правила компиляции · Компилятор · Дефолтные правила · Красивый API · Производительность · Примеры работы · Читать полностью »
Время от времени я встречаю людей, пытающихся выразить API в терминах IQueryable<T>. Почти всегда это плохая идея. В этой статье я объясню почему. В кратце, IQueryable<T> — это один из лучших примеров заголовочного интерфейса (Header Interface), предлагаемых платформой .NET. Его почти невозможно реализовать полностью.
Эта статья о проблемах реализации API на основе интерфейса
IQueryable<T>. Это не претензия к интерфейсу как таковому. Кроме этого, это не претензия к замечательным методам LINQ, доступным для интерфейсаIEnumerable<T>.
Можно сказать, что IQueryable<T> — это одно сплошное нарушение принципа подстановки Лисков. Я буду использовать закон Постела, чтобы объяснить почему это так.
Принцип устойчивости, также известен как закон Постела в честь Джона Постела: «Будь либерален к тому, что принимаешь, и консервативен к тому, что отсылаешь (Be liberal in what you accept, and conservative in what you send)».
Деревья выражений System.Linq.Expressions дают возможность выразить намерения не только самим кодом, но и его структурой, синтаксисом.
Их создание из лямбда-выражений — это, по сути, синтаксический сахар, при котором пишется обычный код, а компилятор строит из него синтаксическое дерево (AST), которое в том числе включает ссылки на объекты в памяти, захватывает переменные. Это позволяет манипулировать не только данными, но и кодом, в контексте которого они используются: переписывать, дополнять, пересылать, а уже потом компилировать и выполнять.