Как говорится we are proud to announce the very first fully functional Linq provider over WCF. Первый в мире полноценный Linq провайдер работающий через WCF.

Качать как всегда здесь.

Критика, замечания, пожелания, особенно специалистов по WCF и защите, приветствуются.

Запустить пример в одном процессе можно примерно так:

using (var host = new ServiceHost(new LinqService(), new Uri("net.tcp://localhost:1234")))
{
    host.Description.Behaviors.Add(new ServiceMetadataBehavior());
    host.Description.Behaviors.Find<ServiceDebugBehavior>().IncludeExceptionDetailInFaults = true;
    host.AddServiceEndpoint(typeof(IMetadataExchange), MetadataExchangeBindings.CreateMexTcpBinding(), "mex");
    host.AddServiceEndpoint(
        typeof(ILinqService),
        new NetTcpBinding(SecurityMode.None)
        {
            MaxReceivedMessageSize = 10000000,
            MaxBufferPoolSize      = 10000000,
            MaxBufferSize          = 10000000,
            CloseTimeout           = new TimeSpan(00, 01, 00),
            OpenTimeout            = new TimeSpan(00, 01, 00),
            ReceiveTimeout         = new TimeSpan(00, 10, 00),
            SendTimeout            = new TimeSpan(00, 10, 00),
        },
        "LinqOverWCF");

    host.Open();

    var ctx = new ServiceModelDataContext(
        new NetTcpBinding(SecurityMode.None)
        {
            MaxReceivedMessageSize = 10000000,
            MaxBufferPoolSize      = 10000000,
            MaxBufferSize          = 10000000,
            CloseTimeout           = new TimeSpan(00, 01, 00),
            OpenTimeout            = new TimeSpan(00, 01, 00),
            ReceiveTimeout         = new TimeSpan(00, 10, 00),
            SendTimeout            = new TimeSpan(00, 10, 00),
        },
        new EndpointAddress("net.tcp://localhost:1234/LinqOverWCF"));

    var list = ctx.GetTable<Person>().ToList();

    host.Close();

    return list;
}

Вкратце как это работает.

BLT Linq провайдер общается с контекстом данных через интерфейс IDataContext, которому передаётся распарсенный Linq запрос в виде структуры SqlQuery. SqlQuery фактически представляет собой SQL AST. ServiceModelDataContext сериализует эту структуру и передаёт LinqService, который в свою очередь формирует SQL, выполняет запрос и возвращает данные клиенту. Всё просто.

Самый больной вопрос в данном подходе, конечно же, безопасность, если она актуальна. LinqService содержит метод ValidateQuery, который можно использовать для валидации запроса. По умолчанию, LinqService всего лишь не позволяет использовать DML операции, но, в принципе, нет никаких проблем сделать более интеллектуальную проверку структуры запроса. Например, на использование несанкционированных таблиц или полей. Собственно говоря, на эту тему хотелось бы побольше поговорить и услышать мнения насчёт типовых сценариев защиты, которые можно было бы реализовать прямо в библиотеке, т.к. хотя SqlQuery и можно анализировать, но в языках не поддерживающих patten matching это занятие не из весёлых.

IT>Как говорится we are proud to announce the very first fully functional Linq provider over WCF. Первый в мире полноценный Linq провайдер работающий через WCF.

Круто! Вот только хотелось бы использовать Linq over WCF из Silverlight

Здравствуйте, Andy77, Вы писали:

IT>>Как говорится we are proud to announce the very first fully functional Linq provider over WCF. Первый в мире полноценный Linq провайдер работающий через WCF.

A>Круто! Вот только хотелось бы использовать Linq over WCF из Silverlight

Над этим работаем. К сожалению, API SL в плане совместимости с FW вещь далеко не идеальная, поэтому придётся много поменять в булките, например, заменить все Hashtable на Dictionary и т.п.

Здравствуйте, IT, Вы писали:

IT>Над этим работаем. К сожалению, API SL в плане совместимости с FW вещь далеко не идеальная, поэтому придётся много поменять в булките, например, заменить все Hashtable на Dictionary и т.п.

public class Hashtable : Dictionary<object, object> {}

Такой способ не пойдёт?

Здравствуйте, koandrew, Вы писали:

K>Такой способ не пойдёт?

Ты действительно думаешь, что проблема в механическом рефакторинге?

Здравствуйте, koandrew, Вы писали:

K>

public class Hashtable : Dictionary<object, object> {}

K>Такой способ не пойдёт?

Нет. Hashtable отличается от Dictionary:

— способом добавления элемента в словать,
— способом проверки существования элемента в словаре,
— поддержкой многопоточности.

Здравствуйте, IT, Вы писали:

IT>Нет. Hashtable отличается от Dictionary:

IT>- способом добавления элемента в словать,
Hashtable.Add(object, object)
Dictionary<TKey.TValue>.Add(TKey key, TValue value) == Dictionary<object, object>.Add(object, object)
=> одинаково
IT>- способом проверки существования элемента в словаре,
Оба класса юзают метод ContainsKey
IT>- поддержкой многопоточности.
Тут есть небольшые различия, это да. Но проблема в принципе решаемая.

Здравствуйте, AndrewVK, Вы писали:

AVK>Ты действительно думаешь, что проблема в механическом рефакторинге?

Я всего лишь предложил путь, которым я сам раньше воспользовался...

Здравствуйте, koandrew, Вы писали:

IT>>- способом проверки существования элемента в словаре,
K>Оба класса юзают метод ContainsKey

Знаешь почему у Hashtable нет метода TryGetValue?

IT>>- поддержкой многопоточности.
K>Тут есть небольшые различия, это да.

Различия весьма серьезные.

K> Но проблема в принципе решаемая.

Простым способом — нет. А сложным — проще отрефакторить.

Здравствуйте, AndrewVK, Вы писали:

AVK>Знаешь почему у Hashtable нет метода TryGetValue?
Потому что хэштаблица выросла из первого фреймворка и там этого метода не было? И дженериков там тоже не было для избежания боксинга?
Этот метод — комбинация метода ContainsKey и индексёра. Оба исполняются за константное время. Цитирую MSDN:

This method combines the functionality of the ContainsKey method and the Item property.

If the key is not found, then the value parameter gets the appropriate default value for the value type TValue; for example, 0 (zero) for integer types, false for Boolean types, and nullNothingnullptra null reference (Nothing in Visual Basic) for reference types.

Use the TryGetValue method if your code frequently attempts to access keys that are not in the dictionary. Using this method is more efficient than catching the KeyNotFoundException thrown by the Item property.

This method approaches an O(1) operation.

Так что проблемы тут нет.

AVK>Различия весьма серьезные.
multiread-singlewrite у хэштаблицы против multiread у словаря. При необходимости допиливается через перекрытие методов после наследования от словаря.

AVK>Простым способом — нет. А сложным — проще отрефакторить.
Мой поинт в том, что может оказаться проще сваять класс Hashtable с нужным поведением (да хоть тупо выдернув его код из "большого" фреймворка рефлектором и собрав под Silverlight), чем выкорчёвывать его из текущей либы, заменяя за словари и втыкая локи...

Здравствуйте, koandrew, Вы писали:

K>Потому что хэштаблица выросла из первого фреймворка и там этого метода не было? И дженериков там тоже не было для избежания боксинга?

Не угадал. Дело в поведении того и другого класса при отсутствии значения по указанному ключу.

AVK>>Различия весьма серьезные.
K>multiread-singlewrite у хэштаблицы против multiread у словаря. При необходимости допиливается через перекрытие методов после наследования от словаря.

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

AVK>>Простым способом — нет. А сложным — проще отрефакторить.
K>Мой поинт в том, что может оказаться проще сваять класс Hashtable с нужным поведением

Не может, уж поверь.

K> (да хоть тупо выдернув его код из "большого" фреймворка рефлектором

Нарушает лицензию. Можно дернуть из Моно, но перформанс куцего джита в SL под вопросом, а родной Dictionary наверняка оптимизирован хардкодно.

Здравствуйте, AndrewVK, Вы писали:

AVK>Не угадал. Дело в поведении того и другого класса при отсутствии значения по указанному ключу.
И? В чём проблема изобразить это поведение?

AVK>Допиливать такие вещи квалифицированно весьма непросто. Кроме того, констренты хештаблицы меньше, это значит придется втыкать автоматические блокировки во всех читающих и пишущих методах, что весьма неслабый объем работы.
В целом одном методе (индексёре)? Ну это несерьёзно

AVK>Не может, уж поверь.
В моём случае оказалось проще...

AVK>Нарушает лицензию. Можно дернуть из Моно, но перформанс куцего джита в SL под вопросом, а родной Dictionary наверняка оптимизирован хардкодно.
У меня проблем с перфомансом под SL не было... Незачем пытаться оптимизировать то, что ещё не факт, что окажется источником проблем.

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

Здравствуйте, koandrew, Вы писали:

IT>>- способом добавления элемента в словать,
K>Hashtable.Add(object, object)
K>Dictionary<TKey.TValue>.Add(TKey key, TValue value) == Dictionary<object, object>.Add(object, object)
K>=> одинаково

hashTable[key] = value;

Если записи с key в таблице нет, то она будет добавлена. На этом можно строить логику.

IT>>- способом проверки существования элемента в словаре,
K>Оба класса юзают метод ContainsKey

var value = hashTable[key];

Если ключа нет в таблице, то вернётся null. Для Dictionary будет исключение.

IT>>- поддержкой многопоточности.
K>Тут есть небольшые различия, это да. Но проблема в принципе решаемая.

Все проблемы решаемые, но для этого нужно повозиться.

Здравствуйте, IT, Вы писали:

IT>hashTable[key] = value;

IT>Если записи с key в таблице нет, то она будет добавлена. На этом можно строить логику.


IT>var value = hashTable[key];

IT>Если ключа нет в таблице, то вернётся null. Для Dictionary будет исключение.

Обе проблемы элементарно решаются переопределением индексёра с добавлением желаемого поведения.
Короче, если вам "ехать", а не шашечки, то больших проблем я не наблюдаю...

Здравствуйте, koandrew, Вы писали:

K>Обе проблемы элементарно решаются переопределением индексёра с добавлением желаемого поведения.
K>Короче, если вам "ехать", а не шашечки, то больших проблем я не наблюдаю...

Это понятно, только затычек с этим SL и так получается не мало. Зачем нам лишняя грязь, которую в принципе можно вычистить.

Здравствуйте, IT, Вы писали:

IT>Это понятно, только затычек с этим SL и так получается не мало. Зачем нам лишняя грязь, которую в принципе можно вычистить.

Если можно — то супер. Я говорю о ситуации, когда "вычистка" чревата переписыванием половины либы...

Здравствуйте, koandrew, Вы писали:

AVK>>Не угадал. Дело в поведении того и другого класса при отсутствии значения по указанному ключу.
K>И? В чём проблема изобразить это поведение?

В лишенй работе.

AVK>>Допиливать такие вещи квалифицированно весьма непросто. Кроме того, констренты хештаблицы меньше, это значит придется втыкать автоматические блокировки во всех читающих и пишущих методах, что весьма неслабый объем работы.
K>В целом одном методе (индексёре)? Ну это несерьёзно

В каком одном? Почти во всех.

K>У меня проблем с перфомансом под SL не было...

Мало ли чего у тебя не было.

K> Незачем пытаться оптимизировать то, что ещё не факт, что окажется источником проблем.

В случае библиотек это не всегда работает.

K>Собственно, если посмотреть на проблему с практической точки зрения, то может оказаться так (и в моём случае так оказалось), что от всего класса хэштаблицы нам нужно реализовать меньше десятка методов (добавление, удаление, выборка по ключу, проверка существования ключа), что не составляет большой проблемы...

Как не составляет особо большой проблемы просто заменить хештаблицу на словарь без костылей.

Здравствуйте, IT, Вы писали:

IT>Как говорится we are proud to announce the very first fully functional Linq provider over WCF. Первый в мире полноценный Linq провайдер работающий через WCF.

уже есть другой, но платный

Здравствуйте, cadet354, Вы писали:

IT>>Как говорится we are proud to announce the very first fully functional Linq provider over WCF. Первый в мире полноценный Linq провайдер работающий через WCF.
C>уже есть другой, но платный

Это полноценный over WCF или поддержка WCF RIA Services?

Здравствуйте, IT, Вы писали:

IT>Как говорится we are proud to announce the very first fully functional Linq provider over WCF. Первый в мире полноценный Linq провайдер работающий через WCF.

Я только мельком глянул — но здесь вроде описывается похожий провайдер:
http://www.hanselman.com/blog/CreatingAnODataAPIForStackOverflowIncludingXMLAndJSONIn30Minutes.aspx

Там запросы описанны с помощью OData/Rest (параметры запроса).

Это аналог? Если да — то буду благодарен, если кто опубликует сравнительные характеристики. Если нет — то что я пропустил?