Комментарии 31
Боюсь прослыть буквоедом, но это не LINQ :)
LINQ'ом будет так:
А так идея классная.
LINQ'ом будет так:
var Banks = from item in cblBanks.Items.Cast<ListItem>()
where item.Selected
select Convert.ToInt32(item.Value);
А так идея классная.
Думаю, все же LINQ. Этот раздел, а конкретно последний абзац утверждает, что обе формы являются основой языка запросов.
Позанудствую. Раз уж LINQ, то синтаксис стоит использовать на полную мощь. Cast можно указывать через имя типа перед объявлением query-переменной - сразу становится нагляднее:
var Banks = from ListItem item in cblBanks.Items
where item.Selected
select Convert.ToInt32(item.Value);
Просто я не люблю данный способ описания LINQ выражения. Созданный для профессионалов SQL он, на мой взгляд, слишком выделяется среди C-подобного кода. Это дело личных предпочтений, и я больше люблю стандартное (так сказать) использование расширений LINQ.
В простых случаях extension methods действительно легче читаются. Но они сложнее поддерживаются и иногда случается путаница с параметрами лямбд (одно и тоже имя обозначает разные типы). Делать сортировку и группировку через методы однозначно неудобно. Вложенные запросы - смерть на взлете.
С другой стороны, синтаксис query на данный момент очень беден, и все равно приходится писать в итоге код через вызовы методов. Но тут спасибо R# и его "query to extension methods chain".
С другой стороны, синтаксис query на данный момент очень беден, и все равно приходится писать в итоге код через вызовы методов. Но тут спасибо R# и его "query to extension methods chain".
Не-не, все верно, это LINQ, точнее его Extention-методы. from xxx in yyy select xxx - это просто упрощенная форма записи и во многих случаях использование Extention-методов напрямую бывает и короче и понятнее, но не всегда. Сложные запросы все-таки лучше через from записывать.
Да-да, был неправ. Действительно, LINQ - это набор методов, а операторы from, in, where - это только расширения языка для LINQ.
Было - бы неплохо писать к какому .NET Framework'у данная статья относится. А то немного путаешься, когда видишь вещи третьего фреймворка, разрабатывая программы на втором.
List comprehensions рулят уже очень давно.
Их упростили для понимания, адаптировали под .Net и добавили :)
Возможности же, действительно очень большие.
Их упростили для понимания, адаптировали под .Net и добавили :)
Возможности же, действительно очень большие.
Мне кажется, при том коде, который у вас есть в ASPX, связать с данными список проще было бы декларативно.
Ну, весь aspx я привел для примера. Так сказать, чтобы показать, что LINQ применима не только для объектов данных типа БД и XML. Как уже написали эта возможность определяется термином LINQ to objects.
Вы не поняли мою мысль. Я бы заменил вашу первую вставку кода на код, приведенный ниже. Хотя может это больше дело вкуса.
<asp:CheckBoxList ID="cblBanks" runat="server"
DataSourceID="dsBanks"
DataValueField="id"
DataTextField="shortName">
</asp:CheckBoxList>
<asp:SqlDataSource ID="dsBanks" runat="server"
ConnectionString="<%$ ConnectionStrings:SampleConnectionString %>"
SelectCommand="SELECT b.id, b.shortName FROM Banks b">
</asp:SqlDataSource>
* This source code was highlighted with Source Code Highlighter.
Самому некогда заняться изучением LINQ. Но по множественным примерам, вижу, что технология чрезвычайно полезная. Хотелось бы еще увидеть что-нибудь типа LINQ to JSON.
чего-то мне не кажется что так будет проще...
Смотря что потом с выбранными данными делать.
Так проще будет в том случае, когда будем использовать LINQ To SQL, например. Мы сможем одним linq запросом вернуть сразу коллекцию банков и одним махом их сразу добавить в другую коллекцию для вставки в БД.
Если же отдельно от остальной логики, то приведенный пример действительно больше кода занимает и в чем-то менее наглядный.
Так проще будет в том случае, когда будем использовать LINQ To SQL, например. Мы сможем одним linq запросом вернуть сразу коллекцию банков и одним махом их сразу добавить в другую коллекцию для вставки в БД.
Если же отдельно от остальной логики, то приведенный пример действительно больше кода занимает и в чем-то менее наглядный.
В простейшем случае мы могли бы пробежаться по коллекции элементов и выбрать те, которые отметил пользователь.
List<int> Banks = new List<int>();
foreach(ListItem li in cblBanks.Items) if (li.Selected) Banks.Add(li);
Решайте сам что выходит проще.
В статье - действительно Extension-методы, которые помимо прочего используются в LinqDataSource, а не LINQ. LINQ же - это инструкции языка, о чем говорит само название технологии (Language INtegrated Query, если вдруг кто не в курсе).
Мы еще в свое время, когда только взялись за LINQ, долго гадали, почему не решается задача, пока не поняли, чем отличается LinqDataSource и LINQ :) Дело в том, что для доступа к LinqDataSource используется как раз набор extension-методов, как в примере из этой статьи, а слово "Linq" в названии типа источника данных фигурирует как раз благодаря тому, что к нему можно обращаться А ЛЯ LINQ, но на самом деле не используя последний. Поэтому есть некоторая путаница.
А, кстати, главная проблема с LINQ, с которой мы столкнулись в разработке - крайне сложное построение LINQ-запросов в Runtime (например, бывает необходимо поместить в запрос параметры, вытащенные, скажем, из XML с настройками).
И еще одна сложность - очень непросто сделать Mock-объект для LINQ DataContext для unit-тестирования. Приходится идти на ухищрения.
А самая прелесть Линкью, на мой взгляд - возможность одинаковым образом обращаться к чему угодно (включая свое собственное), реализующее интерфейс IQueryable.
Мы еще в свое время, когда только взялись за LINQ, долго гадали, почему не решается задача, пока не поняли, чем отличается LinqDataSource и LINQ :) Дело в том, что для доступа к LinqDataSource используется как раз набор extension-методов, как в примере из этой статьи, а слово "Linq" в названии типа источника данных фигурирует как раз благодаря тому, что к нему можно обращаться А ЛЯ LINQ, но на самом деле не используя последний. Поэтому есть некоторая путаница.
А, кстати, главная проблема с LINQ, с которой мы столкнулись в разработке - крайне сложное построение LINQ-запросов в Runtime (например, бывает необходимо поместить в запрос параметры, вытащенные, скажем, из XML с настройками).
И еще одна сложность - очень непросто сделать Mock-объект для LINQ DataContext для unit-тестирования. Приходится идти на ухищрения.
А самая прелесть Линкью, на мой взгляд - возможность одинаковым образом обращаться к чему угодно (включая свое собственное), реализующее интерфейс IQueryable.
Методы расширения - это и есть LINQ. Инструкции (расширения языка C#), про которые вы говорите, могли бы вообще не существовать. Факт наличия LINQ от этого не изменился бы, почитайте wiki http://en.wikipedia.org/wiki/Language_In….
Говорить "чем отличается LinqDataSource и LINQ" в принципе не верно. Это как сравнивать теплое с мягким. Еще раз настоятельно рекомендую вам ознакомится со статьей в wiki, чтобы вы окончательно развеяли свою заблуждения насчет того, что такое LINQ.
Говорить "чем отличается LinqDataSource и LINQ" в принципе не верно. Это как сравнивать теплое с мягким. Еще раз настоятельно рекомендую вам ознакомится со статьей в wiki, чтобы вы окончательно развеяли свою заблуждения насчет того, что такое LINQ.
Методы расширения лежат на более низком уровне в основе LINQ. Т.е. сами механизмы, используемые LINQ, реализованы с помощьью Extension-методов. Это я в курсе!
Более того, когда мы реализуем собственный вариант, скажем, IQueryable-объекта, мы реализуем именно МЕТОДЫ Where, Select, SelectMany и многе другие.
Отчасти я согласен, что все это в комплексе можно называть LINQ, но я лишь говорил, что в целом LINQ - это именно "Language Integrated", то есть не методы, а инструкции языка C# 3.0, такие как select, where и так далее.
Про отличие LinqDataSource и LINQ - я как раз и говорил про некоторую путаницу с тем, почему у него приставка "Linq-", учитывая мое предыдущее предложение.
Это не более чем другой взгляд, который, однако, может сбить с толку того, кто с этим только начинает работать.
Более того, когда мы реализуем собственный вариант, скажем, IQueryable-объекта, мы реализуем именно МЕТОДЫ Where, Select, SelectMany и многе другие.
Отчасти я согласен, что все это в комплексе можно называть LINQ, но я лишь говорил, что в целом LINQ - это именно "Language Integrated", то есть не методы, а инструкции языка C# 3.0, такие как select, where и так далее.
Про отличие LinqDataSource и LINQ - я как раз и говорил про некоторую путаницу с тем, почему у него приставка "Linq-", учитывая мое предыдущее предложение.
Это не более чем другой взгляд, который, однако, может сбить с толку того, кто с этим только начинает работать.
Хм, покопаюсь в MSDN, интересно стало, что я не так понимаю.
Да, пожалуй, +1.
MS Сами называют LINQ'ом именно весь механизм, начиная от Extension-методов, а операторы языка являются опциональным "приятным дополнением".
Спасибо за выражение сомнений :)
MS Сами называют LINQ'ом именно весь механизм, начиная от Extension-методов, а операторы языка являются опциональным "приятным дополнением".
Спасибо за выражение сомнений :)
Смысл статьи — вариант использования, а ЛИНК или другое — это вторично.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
LINQ: еще один вариант использования