Фильтрация коллекций в отладочных окнах Visual Studio

Большинство .Net разработчиков знакомы с лямбда-выражениями (lambda expressions) и активно их используют. Однако при попытке использовать их в таких отладочных окнах как Watch / Immediate и Locals, Visual Studio сообщит нам о том, что “Expression cannot contain lambda expressions”. На это есть свои причины, и они очень подробно изложены в этих постах. К сожалению, в них также отсутствует информация о решении данной проблемы. В то время как разработчики каждый день сталкиваются с необходимость фильтрации коллекций в режиме отладки и поддержка лямбда-выражений значительно упростила бы их труд.

Визуализаторы

Самое первое решение появилось, как ни странно, ещё задолго до самих лямбда-выражений и основано на способе отображения отладочной информации в Visual Studio.

Встроенный отладчик отображает значения переменных или объектов с помощью, так называемых визуализаторов – компонентов пользовательского интерфейса. Из коробки доступны 5 различных визуализаторов для работы с:

1. Текстом;
2. HTML;
3. XML;
4. Деревом визуальных компонентов WPF;
5. Набором данных представленных объектами DataSet, DataView и DataTable.

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

Поэтому первым решением была таблица данных, отображающая коллекцию объектов со всеми его свойствами и позволяющая настроить правила фильтрации с помощью коллекции преопределённых фильтров:



Не самый удобный способ — открывать каждый раз отдельное окно для задания условий фильтрации, поэтому поиски продолжались.

Entity SQL

Годом позже, в процессе подготовки к сдаче экзамена 70-516: TS: Accessing Data with Microsoft .NET Framework 4 я внимательно изучал Entity SQL, о котором я до этого только слышал (если не считать опыта работы с HQL). Для тех, кто не в курсе, что это за зверь, приведу определение из MSDN:

Entity SQL представляет собой независимый от хранилища язык, подобный языку SQL. Язык Entity SQL предназначен для запросов и управления большим количеством графов объектов, основанных на концептуальной модели.

Т.е. в Entity Framework мы можем описать условие фильтрации в виде строки. Пример:

using (var context = new CountriesEntities())
{
    var countriesStartWithA = context.Countries.Where("it.Name LIKE 'A%'");
}

* This source code was highlighted with Source Code Highlighter.

Object SQL

Думаю вы уже догадались, что запись лямбда-выражений в строковом виде – способ обойти проблему с отладчиком Visual Studio. В итоге были написаны методы расширения (extension methods) для Linq-to-Object, принимающие на вход строковые фильтры. По аналогии с Entity SQL они были названы Object SQL. Достоинства и недостатки такого решения очевидны. Единственно, что я хотел бы отметить это альтернативный синтаксис. Дело в том, что у нас уже есть ещё один формат задания условий фильтрации в текстовом виде, используемый в протоколе OData. И приведённый выше фильтр можно было бы переписать как:

using (var context = new CountriesEntities())
{
    var countriesStartWithA = context.Countries.Filter("$filter=startswith(Name,'A')");
}

* This source code was highlighted with Source Code Highlighter.

Честно говоря, я ждал поддержки лямбда-выражений вместе с релизом Visual Studio 2010, но увы. Поэтому приходится мириться с несовершенством рабочего инструмента и искать обходные пути.

P.S.: Надеюсь товарищ outcoldman пролоббирует этот вопрос в команде разработчиков Visual Studio