Комментарии 21
Существует еще библиотека LINQ.Dynamic, которая позволяет делать примерно то же самое, указывая вместо лямбд строки.
Да, слышал про такое. Но нам неудобно было строить строку на клиенте, т.к. используется много условий построений фильтров. И порой результирующее правило получалось из 3-7 операндов разного уровня вложенности. Согласитесь, не всегда удобно будет разбирать и дополнять строку, гораздо удобнее строить js объект. Согласен, можно было бы потом разбирать js объект в строку и использовать dlinq, но нам нужны были доп. условия, которые не вошли в проект на гитхабе. Раз уж сделали, почему бы не поделиться с людьми? Да и в конце я написал, что мы не рассчитывали на звание первооткрывателя, а только лишь делали под свое удобство.
А зачем JSON? Те же строки odata выглядят сильно короче (см. тут, первый же пример Uri в разделе 2).
Плюс, советую добавить логические операции в where фильтры (или в readme на гитхабе).
Плюс, советую добавить логические операции в where фильтры (или в readme на гитхабе).
Говорю же, нам удобнее было использовать именно в виде построения js объекта. Не спорю, есть множество более удобных решений. В любом случае это был отличный опыт.
Забыл сразу написать, извиняюсь за флуд, но спасибо за предложение, обязательно добавим логические операции.
Вот еще клиент будет указывать серверу как выборку делать
Обычный пример эволюции проэкта и людей которые проэкт пишут.
Потом внезапно нагугливается OData WEB API, и наступает прозрение.
Потом внезапно нагугливается OData WEB API, и наступает прозрение.
Проект очень старый, плюс он используется в разных регионах на отдельных серверах. Первая версия этой библиотеки была написана более трех лет назад. Сейчас ее используют у нас более 50 страниц. Нам было бы очень проблемно сменить технологию, поэтому мы ее только довели до ума.
Чем больше вы будете работать над своим API, тем сложнее вам будет его модифицировать при таком подходе. Ни один раз проходили эту ситуацию. OData сущесвенно упращает жизнь, проверено :)
А можете посоветовать адекватные js библиотеки для работы с OData? Желательно Free/Libre and Open-Source Software
Мой совет просто используйте голый стандарт 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, но увы.
Я выбрал второе.
Код примерно такой:
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, но увы.
К сожалению, является MS детищем и нормально реализовано только в .NET.
Вы бы стали использовать этот подход в новом проэкте?
Да, так как есть уже наработанный функционал.
Посмотрите сколько стоит поддержка Вашей библиотеки, и посмотрите на OData к примеру.
Сравните возможности и думаю все станет понятно.
P. S. Сам был в такой ситуации, итог новое на OData, старое живет со старым и потихоньку переписывается.
Создание таких библиотек дело веселое но в целом вредно для проэкта.
Вы никогда не напишите лучше чем 70+ контрибьюторов с подержкой Microsoft.
Сравните возможности и думаю все станет понятно.
P. S. Сам был в такой ситуации, итог новое на OData, старое живет со старым и потихоньку переписывается.
Создание таких библиотек дело веселое но в целом вредно для проэкта.
Вы никогда не напишите лучше чем 70+ контрибьюторов с подержкой Microsoft.
Увы, костыльненькое решение. Как-то жестко напрягает хардкодность. Логические И и ИЛИ напугали если честно. Почему за основу не взять Expression Tree? Есть операнд и есть его параметры, есть к примеру FEqual, FGreater, FLess, FNot, FAnd, FOr и этого достаточно чтобы построить чуть ли не всё что угодно, добавить еще FContains, хватит. В итоге если надо построить выражение типа p1 !=… && (p2 ==… || p2 == ...), описывается легко
FAnd(FNot(FEqual), FOr(FEqual, FEqual)), а вводить какие-то деревья, в которых указывать как их обрабатывать, это какое-то извращение.
FAnd(FNot(FEqual), FOr(FEqual, FEqual)), а вводить какие-то деревья, в которых указывать как их обрабатывать, это какое-то извращение.
Вообще проблема весьма актуальна.
Даже server-side ORM обычно «спотыкается» на нестандартных свойствах той или иной БД и иногда проще написать голый SQL-запрос (благо, все ORM позволяют это сделать), чем бороться с вычурными конструкциями.
На client-side все еще хуже, если вы лишены роскоши «70+ контрибьюторов с подержкой Microsoft», то приходится писать свой велосипед, чем здесь многие и занимаются.
Даже server-side ORM обычно «спотыкается» на нестандартных свойствах той или иной БД и иногда проще написать голый SQL-запрос (благо, все ORM позволяют это сделать), чем бороться с вычурными конструкциями.
На client-side все еще хуже, если вы лишены роскоши «70+ контрибьюторов с подержкой Microsoft», то приходится писать свой велосипед, чем здесь многие и занимаются.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
LINQ: Динамическое построение фильтров запросов