Comments 31
Боюсь прослыть буквоедом, но это не LINQ :)
LINQ'ом будет так:
А так идея классная.
LINQ'ом будет так:
var Banks = from item in cblBanks.Items.Cast<ListItem>()
where item.Selected
select Convert.ToInt32(item.Value);
А так идея классная.
Позанудствую. Раз уж 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'у данная статья относится. А то немного путаешься, когда видишь вещи третьего фреймворка, разрабатывая программы на втором.
...в то время когда у пользователей стоит первый.
Я считаю,что достаточно и так понятно - LINQ - это нововведение третьего фреймворка, но установив language extensions for С#, можно и на 2005 студии это писать.
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-методов, а операторы языка являются опциональным "приятным дополнением".
Спасибо за выражение сомнений :)
Смысл статьи — вариант использования, а ЛИНК или другое — это вторично.
Sign up to leave a comment.
LINQ: еще один вариант использования