Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

10 мифов о LINQ

Anna | 17.06.2014 | нет комментариев

Миф #1

Все LINQ запросы обязаны начинаться с ключевого слова ‘var’. По сути основная цель ключевого слова ‘var’ — начать LINQ запрос!


Ключевое слово var и LINQ — это независимые доктрины. Ключевое слово var разрешает компилятору вывести тип локальной переменной на основании исходного присваивания(неявная типизация). К примеру, дальнейший код:

var s = "Hello"; 

точный эквивалент для:

string s = "Hello"; 

потому что компилятор выводит тип переменной s как string.
Подобно, дальнейший запрос:

string[] people = new [] { "Tom", "Dick", "Harry" };
var filteredPeople = people.Where (p => p.Length > 3); 

точный эквивалент для:

string[] people = new [] { "Tom", "Dick", "Harry" };
IEnumerable<string> filteredPeople = people.Where (p => p.Length > 3); 

Дозволено подметить, всё чего мы добились с поддержкой ключевого слова var — это сделали сокращение для IEnumerable<string>. Многие люди любят такую запись, от того что она короче; другие же считают, что неявная типизация способна сделать код менее внятным.

Бывают обстановки, в которых для LINQ запросов нужно ключевое слово var. Это происходит при проекции внеизвестный тип:

string[] people = new [] { "Tom", "Dick", "Harry" };
var filteredPeople = people.Select (p => new { Name = p, p.Length }); 

Дальнейший пример показывает, как применять неизвестный тип вне LINQ контекста:

var person = new { Name = "Foo", Length = 3 };

Миф #2

Все LINQ запросы обязаны применять синтаксис запросов.

Существует два метода записи LINQ запросов: лямбда синтаксис и синтаксис запросов.

Пример лямбда синтаксиса:

string[] people = new [] { "Tom", "Dick", "Harry" };
var filteredPeople = people.Where (p => p.Length > 3); 

Пример, подобный предыдущему но использующий синтаксис запросов:

string[] people = new [] { "Tom", "Dick", "Harry" };
var filteredPeople = from p in people where p.Length > 3 select p; 

Логически, компилятор транслирует синтаксис запросов в лямбда синтаксис. Это обозначает, что всё, что может быть выражено с поддержкой синтаксиса запросов, так же может быть выражено в лямбда синтаксисе. Синтаксис запросов может быть гораздо проще с запросами включающими больше одной переменной диапазона. (В данном примере, мы применяли только одну переменную диапазона p, так что оба запроса выглядят идентично легко).

Не все операторы доступны в синтаксисе запросов, так что эти два вида синтаксиса скорее дополняют друг друга. Дабы получить лучшее от всякого, вы можете смешивать жанры запросов в одном выражении (см. миф # 5).

Миф #3

Дабы извлечь всех заказчиков из таблицы, вы обязаны применять запрос на подобии этого:
var query = from c in db.Customers select c.

Выражение

from c in db.Customers select c 

является слишком многословным! Вы можете легко применять:

db.Customers

Подобно, дальнейший LINQ to XML запрос:

var xe = from e in myXDocument.Descendants ("phone") select e;

может быть упрощен до:

var xe = myXDocument.Descendants ("phone");

И данный запрос:

Customer customer = (from c in db.Customers where c.ID == 123 select c)
                    .Single();

дозволено упростить до:

Customer customer = db.Customers.Single (c => c.ID == 123);

Миф #4

Дабы воспроизвести SQL запрос в LINQ, вы обязаны сделать LINQ запрос максимально схожим на SQL запрос.

LINQ и SQL — различные языки, использующие различные доктрины.

Допустимо, основным барьером плодотворного применения LINQ является синдром «думать в терминах SQL»: мысленно представлять запрос на языке SQL, а после этого переводить его на LINQ. Итогом будет непрерывная единоборство с API!

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

Миф #5

Для результативного соединения в LINQ, вы обязаны применять ключевое слово join.

Это правда, но только для запросов к локальным коллекциям. Когда вы создаете запрос к базе данных, ключевое слово join совсем необязательно: операция соединения может быть заменена применением нескольких from-ов и подзапросов. Несколько from-ов и подзапросы являются больше универсальными: вы так же можете реализовать соединение не по равенству (non-equi-join).

Больше того в LINQ to SQL и Entity Framework вы можете запрашивать свойства ассоциации, сокращающие надобность в join-ах! К примеру, дальнейший код показывает, как дозволено извлечь имена и идентификаторы всех заказчиков, не совершивших ни одной покупки:

from c in db.Customers
where !c.Purchases.Any()
select new { c.ID, c.Name } 

Либо извлечь заказчиков, не совершивших покупку на сумму свыше $1000:

from c in db.Customers
where !c.Purchases.Any (p => p.Price > 1000)
select new { c.ID, c.Name } 

Подметьте, мы смешали лямбда синтаксис и синтаксис запросов. Большее число примеров свойств ассоциации, начальства по соединениям и смешанного синтаксиса смотри на LINQPad.

Миф #6

От того что итогом SQL запроса является плоский комплект данных, то LINQ запросы обязаны создаваться так, Дабы возвращать также плоский комплект данных.

Это следствие из Мифа #4. Одно из основных превосходств LINQ заключается в том, что вы можете:

  1. Запрашивать структурированный объект через свойства ассоциации (взамен того Дабы соединяться вручную);
  2. Проецировать прямо в иерархию объектов.

В тезисе, 1 и 2 само­стоятельны, впрочем 1 помогает 2. К примеру, если вы хотите извлечь номера заказчиков в штате WA совместно с их покупками, вы можете применять дальнейший код:

from c in db.Customers
where c.State == "WA"
select new
{
   c.Name,
   c.Purchases    // An EntitySet (collection)
}

Иерархический итог этого запроса гораздо проще в работе, чем плоский комплект данных.

Мы можем добиться такого же итога, не применяя свойства ассоциаций:

from c in db.Customers
where c.State == "WA"
select new
{
   c.Name,
   Purchases = db.Purchases.Where (p => p.CustomerID == c.ID)
}

Миф #7

Дабы реализовать внешнее соединение в LINQ to SQL вы неизменно обязаны применять оператор DefaultIfEmpty().

Это правда, если вам необходим плоский комплект данных. Пример в предыдущем мифе, транслируется в левое внешнее соединение (left outer join) в SQL и не требует оператора DefaultIfEmpty.

Миф #8

Запросы LINQ to SQL либо Entity Framework будут выпол

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB