Есть желание пробросить объект типа IQueryable через собственный шлюз TCP/IP. Нужно пробросить именно IQueryable, чтобы не делать кучу методов с параметрическим поиском и не тащить всю коллекцию на клиента, а передавать только то, что клиент запросил. Для этого надо его сериализовать. Сериализовать в лоб его не получается. Можно попробовать сериализовать Expression. Но что-то не нашел, как после десериализации его использовать. Кто может подсказать, куда вообще копать?

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

> куда вообще копать?

Expression Tree Serializer.

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

N_C>Есть желание пробросить объект типа IQueryable через собственный шлюз TCP/IP. Нужно пробросить именно IQueryable, чтобы не делать кучу методов с параметрическим поиском и не тащить всю коллекцию на клиента, а передавать только то, что клиент запросил. Для этого надо его сериализовать. Сериализовать в лоб его не получается. Можно попробовать сериализовать Expression. Но что-то не нашел, как после десериализации его использовать. Кто может подсказать, куда вообще копать?


Вам может проще OData использовать. Для 4-й версии на клиенте можно как раз сгенерировать IQueryable который будет транслировать вызовы в вызовы OData сервиса

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

N_C>Кто может подсказать, куда вообще копать?

Можно поглядеть в сторону linq2db, на то что в папочке ServiceModel.

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

_>Expression Tree Serializer.
Уж пробовал, использовал List<>, взял от него IQueryable, сериализовал. Десериализовать не получилось.

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

Tom>Вам может проще OData использовать. Для 4-й версии на клиенте можно как раз сгенерировать IQueryable который будет транслировать вызовы в вызовы OData сервиса
У меня уже есть отлаженный сервис, и это не WCF... Боюсь, что OData потребует больших телодвижений.

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

AVK>Можно поглядеть в сторону linq2db, на то что в папочке ServiceModel.
У нас уже есть EF. Насколько оправданно применение еще и linq2db?

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

N_C>У нас уже есть EF. Насколько оправданно применение еще и linq2db?

Не обязательно же весь linq2db применять. Исходники доступны, можно использовать ровно столько, сколько требуется.

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

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

_>>Expression Tree Serializer.
N_C>Уж пробовал, использовал List<>, взял от него IQueryable, сериализовал. Десериализовать не получилось.

Странно, что сериализовать получилось. Зачем сам IQueryable-объект сериализовать? Сериализуют/десериализуют Expression (запрос к нему, то бишь)!

Пример.

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

_>Expression Tree Serializer.

У сериализации ET есть одна фундаментальная проблема — дерево может содержать представление кода, определённого только на клиенте. Тогда на сервере десериализовывать будет нечего. Т.е. это всё может работать, а может и не работать в зависимости от того какой код напишет программист.

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

> Т.е. это всё может работать, а может и не работать в зависимости от того какой код напишет программист.

Дык, кто ж спорит. Само собой.

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

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

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

_>>>Expression Tree Serializer.
N_C>>Уж пробовал, использовал List<>, взял от него IQueryable, сериализовал. Десериализовать не получилось.
_>Странно, что сериализовать получилось. Зачем сам IQueryable-объект сериализовать? Сериализуют/десериализуют Expression (запрос к нему, то бишь)!
Вот такой код — возвращает в итоге null

var ds = new List<string>() {"abc", "def", "ghi"};
var exp1 = ds.AsQueryable().Select(r => r);
var xml = exp1.SerializeQuery();
ExpressionSerializer es = new ExpressionSerializer();
var exp2 = es.Deserialize(xml);
return exp2;

А вот такой — приводит к эксепшну: "Invalid cast from 'System.String' to 'System.Linq.EnumerableQuery`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]'"

var ds = new List<string>() {"abc", "def", "ghi"};
var exp1 = ds.AsQueryable().Select(r => r);
var xml = ExpressionSerializer.Serialize(exp1.Expression);
ExpressionSerializer es = new ExpressionSerializer();
var exp2 = es.Deserialize(xml);
return exp2;

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

N_C>А вот такой — приводит к эксепшну: "Invalid cast from 'System.String' to 'System.Linq.EnumerableQuery`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]'"

А надо как-то так:

public static IEnumerable<string> GetStrings()
{
    return new List<string>() { "abc", "def", "ghi" };
}

static void Main(string[] args)
{            
    Expression<Func<IEnumerable<string>>> exp1 = () => from s in GetStrings() select s;

    ExpressionSerializer es = new ExpressionSerializer(new TypeResolver(new[] { typeof(Program).Assembly }));
    var xml = es.Serialize(exp1);
    var exp2 = es.Deserialize(xml);
}

Впрочем, я не настаиваю. Либа — действительно не фонтан в плане удобства и качества.

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

_> ExpressionSerializer es = new ExpressionSerializer(new TypeResolver(new[] { typeof(Program).Assembly }));
В последней версии библиотеки нет параметрического конструктора

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

_> var xml = es.Serialize(exp1);
И метод Serialize стал статическим...

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

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

Tom>>Вам может проще OData использовать. Для 4-й версии на клиенте можно как раз сгенерировать IQueryable который будет транслировать вызовы в вызовы OData сервиса
N_C>У меня уже есть отлаженный сервис, и это не WCF... Боюсь, что OData потребует больших телодвижений.
OData требует очень мало движений и не требует вообще WCF.
очень советую потратить некоторое время что бы разобраться.

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

Tom>OData требует очень мало движений и не требует вообще WCF.
Tom>очень советую потратить некоторое время что бы разобраться.
Хм... OData — это же протокол запроса обмена данными. Есть реализация преобразования IQueryable в запрос OData?
По сути, мне важна именно возможность динамического формирования фильтров для исходного списка данных.
Это можно реализовать через список параметрических методов, простой текстовой строкой со списком фильтров или через объект IQueryable. Сейчас меня интересует именно третий вариант.

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

Tom>OData требует очень мало движений и не требует вообще WCF.
Tom>очень советую потратить некоторое время что бы разобраться.
В дополнение — IQueryable мне нужен не только для фильтрации получаемых данных на сервере, но и для преобразований типов, которые доступны в LINQ-запроса.

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

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

Tom>>OData требует очень мало движений и не требует вообще WCF.
Tom>>очень советую потратить некоторое время что бы разобраться.
N_C>Хм... OData — это же протокол запроса обмена данными. Есть реализация преобразования IQueryable в запрос OData?
Да.
http://blogs.msdn.com/b/odatateam/archive/2014/03/11/how-to-use-odata-client-code-generator-to-generate-client-side-proxy-class.aspx

N_C>По сути, мне важна именно возможность динамического формирования фильтров для исходного списка данных.
IQueryable + OData для этого идеальный случай, а на сервере EntityFramework, в итоге всей работы на всё пра всё час максимум.

N_C>Это можно реализовать через список параметрических методов, простой текстовой строкой со списком фильтров или через объект IQueryable. Сейчас меня интересует именно третий вариант.

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

N_C>Хм... OData — это же протокол запроса обмена данными. Есть реализация преобразования IQueryable в запрос OData?
Есть, но OData несколько убог. Например, OrderBy после Select не работает. Постоянно будешь натыкаться на подобные ограничения.

@IT&Co: я правильно понимаю, что LinqService в linq2db полноценен (т.е. нет такого linq-запроса, который бы работал напрямую черезз DataConnection, но не работал удаленно через LinqService)?