LINQ: Динамическое построение фильтров запросов

[impwx]

Существует еще библиотека LINQ.Dynamic, которая позволяет делать примерно то же самое, указывая вместо лямбд строки.

[mrxten]

Да, слышал про такое. Но нам неудобно было строить строку на клиенте, т.к. используется много условий построений фильтров. И порой результирующее правило получалось из 3-7 операндов разного уровня вложенности. Согласитесь, не всегда удобно будет разбирать и дополнять строку, гораздо удобнее строить js объект. Согласен, можно было бы потом разбирать js объект в строку и использовать dlinq, но нам нужны были доп. условия, которые не вошли в проект на гитхабе. Раз уж сделали, почему бы не поделиться с людьми? Да и в конце я написал, что мы не рассчитывали на звание первооткрывателя, а только лишь делали под свое удобство.

[Oxoron]

А зачем JSON? Те же строки odata выглядят сильно короче (см. тут, первый же пример Uri в разделе 2).
Плюс, советую добавить логические операции в where фильтры (или в readme на гитхабе).

[mrxten]

Говорю же, нам удобнее было использовать именно в виде построения js объекта. Не спорю, есть множество более удобных решений. В любом случае это был отличный опыт.

[Oxoron]

В любом случае это был отличный опыт.

Да я ж не спорю, сам подобный велосипед пилил.

Говорю же, нам удобнее было использовать именно в виде построения js объекта. Не спорю, есть множество более удобных решений.

А вот тут уже интересно. Чем именно вам не угодили «более удобные» решения?

[mrxten]

Из-за множества условий построений фильтров, нам было неудобно разбирать строку как в DLINQ, чтобы ее дополнить. Так же мы планируем расширить FilterType в Where-фильтре собственным функционалом.

[mrxten]

Забыл сразу написать, извиняюсь за флуд, но спасибо за предложение, обязательно добавим логические операции.

[rzakirovt]

Вот еще клиент будет указывать серверу как выборку делать

[mrxten]

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

[Vitalii_Panchenko]

Обычный пример эволюции проэкта и людей которые проэкт пишут.
Потом внезапно нагугливается OData WEB API, и наступает прозрение.

[mrxten]

Проект очень старый, плюс он используется в разных регионах на отдельных серверах. Первая версия этой библиотеки была написана более трех лет назад. Сейчас ее используют у нас более 50 страниц. Нам было бы очень проблемно сменить технологию, поэтому мы ее только довели до ума.

[correy]

Чем больше вы будете работать над своим API, тем сложнее вам будет его модифицировать при таком подходе. Ни один раз проходили эту ситуацию. OData сущесвенно упращает жизнь, проверено :)

[forcewake]

А можете посоветовать адекватные js библиотеки для работы с OData? Желательно Free/Libre and Open-Source Software

[Vitalii_Panchenko]

Мой совет просто используйте голый стандарт OData. Когда я стоял перед выбором библиотеки на js, я задал себе вопрос «что учить?» API js библиотеки и API OData запросов или просто API OData запросов.
Я выбрал второе.

Код примерно такой:

var request = {
$filter: «some filter»,
$orderby: «field name»,
$top: 10
};

var response = $httpService.get(request);

P. S. В проэкте используем Angular 1.5, нормальное под Angular не нашел. Возможно для других библиотек чтото есть. Классно было бы получить к примеру angular ui grid кторый с коробки работает с OData endpoint, но увы.

[robert_ayrapetyan]

К сожалению, является MS детищем и нормально реализовано только в .NET.

[Vitalii_Panchenko]

Вы бы стали использовать этот подход в новом проэкте?

[mrxten]

Да, так как есть уже наработанный функционал.

[Vitalii_Panchenko]

Посмотрите сколько стоит поддержка Вашей библиотеки, и посмотрите на OData к примеру.

Сравните возможности и думаю все станет понятно.

P. S. Сам был в такой ситуации, итог новое на OData, старое живет со старым и потихоньку переписывается.
Создание таких библиотек дело веселое но в целом вредно для проэкта.
Вы никогда не напишите лучше чем 70+ контрибьюторов с подержкой Microsoft.

[AxisPod]

Увы, костыльненькое решение. Как-то жестко напрягает хардкодность. Логические И и ИЛИ напугали если честно. Почему за основу не взять Expression Tree? Есть операнд и есть его параметры, есть к примеру FEqual, FGreater, FLess, FNot, FAnd, FOr и этого достаточно чтобы построить чуть ли не всё что угодно, добавить еще FContains, хватит. В итоге если надо построить выражение типа p1 !=… && (p2 ==… || p2 == ...), описывается легко
FAnd(FNot(FEqual), FOr(FEqual, FEqual)), а вводить какие-то деревья, в которых указывать как их обрабатывать, это какое-то извращение.

[mrxten]

Спасибо, взгляну.

[robert_ayrapetyan]

Вообще проблема весьма актуальна.
Даже server-side ORM обычно «спотыкается» на нестандартных свойствах той или иной БД и иногда проще написать голый SQL-запрос (благо, все ORM позволяют это сделать), чем бороться с вычурными конструкциями.
На client-side все еще хуже, если вы лишены роскоши «70+ контрибьюторов с подержкой Microsoft», то приходится писать свой велосипед, чем здесь многие и занимаются.