Когда я должен использовать LINQ для C#? [закрытый]

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

var circles =
        from s in allShapes
        where s.Type == ShapeTypes.Circle
        select s;

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

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

Это зависит от того, что вы имеете в виду LINQ.

Это linq-to-sql? В этом случае это ORM со всеми такими же преимуществами, которые приходят с использованием любого другого ORM. Я не использую это много и не могу сказать больше.

Это linq-to-объекты? В этом случае вы действительно говорите о коллекции других вещей: методы расширения, ленивые итераторы и синтаксис понимания запроса. Это введение в мир функционального программирования. Мне больше нельзя использовать для синтаксиса понимания запроса, но для остальных я могу наилучшим образом продемонстрировать с примером.

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

int SumXValues(string filename)
{
    string line;
    int sum = 0;
    int count = 0;
    using (var rdr = new StreamReader(filename))
    {

        while ( (line = rdr.ReadLine()) != null && count < 10)
        {
           int val;
           if (int.TryParse(line.Substring(3,3))
           {
               if (val > 4 && val < 25)
               {
                    sum += val;
                    count ++;
               }
            }
        }
    }
    return sum;
}

Вот новый способ:

IEnumerable<string> ReadLines(string filename)
{
    string line;
    using (var rdr = new StreamReader(filename))
        while ( (line = rdr.ReadLine()) != null)
           yield return line;
}

int SumXValues(string filename)
{
    return ReadLines(filename)
               .Select(l => l.Substring(3,3))
               .Where(l => int.TryParse(l))
               .Select(i => int.Parse(i))
               .Where(i => i > 4 && i < 16)
               .Take(10)
               .Sum(i => i);
}

Обратите внимание, что новый код на самом деле короче. Но почему это также лучше? Есть (как минимум) 4 причины:

• , надеюсь, это очевидно, как повторно использование функции readlines. Вы также можете учитывать больше, но точка - показать, как этот стиль помогает вам повторно использовать больше кода.
• Это масштабируется лучше. Обратите внимание на все привязыванные вызовы функций в этой последней функции. Вы знаете, сколько раз этот код будет итератор по линии в вашем файле? Ровно один раз! На самом деле даже не так долго, как оно остановит чтение из файла после принятия первых 10 предметов. И если вы измените его, чтобы вернуть перечисленное время, а затем использовать это в другом месте с другими методами расширения? Все еще один раз! Это позволяет создавать, смешивать и повторно перемешать ваши результаты запроса во время выполнения без дорогостоящих дополнительных проходов в ваших списках.
• Это более удобно. Если критерии изменяются, легко определить точное «правило» (если вы будете получать), что вы заботитесь и измените только эту часть.
• Это более читаемо. Это позволяет выразить код с точки зрения того, что он делает, а не то, как он это делает.

Да, вы можете легко использовать LINQ to Objects, используя альтернативный код, и это несложно. Мне нравится семантика лямбда-выражений, и она действительно объединяет несколько строк кода в одну. Но многие операции вы можете выполнять со своим собственным кодом, за исключением некоторых более крупных операций (объединение, пересечение и т. Д.), Которые легче выполнять с LINQ.

У LINQ есть и другие особенности; LINQ to XML упрощает работу с XML-данными. Мне он очень нравится больше, чем предыдущие доступные объекты.

LINQ to SQL и ADO.NET Entity Framework (с LINQ to Entities) представляют собой объектно-реляционные сопоставители, которые могут сопоставляться с таблицами базы данных и действовать как хранимые процедуры и наборы данных ADO.NET, так что это очень хорошая альтернатива. чем слабые наборы данных / таблицы данных, и мне тоже нравится это над строго типизированными наборами данных / таблицами.

HTH.

Считаю полезным преобразовывать/"проектировать" данные перед их привязкой к сетке для целей только чтения.

Квотирование целых чисел в SQL имеет лишь незначительный штраф за производительность. Удаление кавычек намного меньше работы, чем преобразование представления ASCII в двоичное целое число.

Поэтому я бы сказал, что это вполне приемлемо, особенно для структуры RAD.

Можно создать консольное приложение, а затем изменить его свойства в параметрах настройки проекта на приложение Windows (а не консоль). Также можно создать приложение Windows Forms, которое не создает формы.

Кто-то упомянул, что LINQ является декларативным стилем программирования. Я просто хотел расширить это.

Одним из способов использования LINQ является запись тестового кода oracle. Очень важно, чтобы тестовый код был простым и как можно ближе к «очевидно правильному», иначе он будет иметь столько ошибок, сколько он должен проверить. С одной конкретной функцией, которую я тестирую сейчас, я написал небольшой список наборов понятий, которые точно описывают, как я ожидаю, что функция будет работать. Благодаря LINQ преобразование этих понятий в код становится тривиально простым:

A = all items
B = [x in A: x.Type = selectedtype, x.Source = "sourceA"]
C = [x in A: x.Source = "sourceB"]
D = B union C

В коде:

IEnumerable<MyClass> SetB(IEnumerable<MyClass> allItems, MyType type)
{
  var result = from item in allItems
               where item.Type == type && item.Source == "sourceA"
               select item;
  return result;
}

IEnumerable<MyClass> SetC(IEnumerable<MyClass> allItems)
{
  var result = from item in allItems
               where item.Source == "sourceB"
               select item;
  return result;
}

IEnumerable<MyClass> SetD(IEnumerable<MyClass> allItems, MyType type)
{
  var setB = SetB(allItems, type);
  var setC = SetC(allItems);
  return setB.Union(setC);
}

Хотя все еще немного более подробным, чем математические выражения, гораздо проще и проще называть «очевидно правильным», чем императивный код. Код LINQ является декларативным, как и математический код. Меньше перевода, ближе к spec. LINQ, когда используется соответствующим образом, в значительной степени язык «Делать то, что я имею в виду».

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