Comments 9
Зачем быть коробочным программистом?
Ну потому что даже глядя на заглавную страницу понятно, что там клиенту очень много позволено будет. Ну или точно так же с валидаторами извращаться, чтобы запретить всё, что клиенту не нужно.
В "Dynamic LINQ" передаваемые строковые выражения точно так же сначала преобразуются в типизированные lambda expressions - в чем тут отличие от того, что придумал автор?
У автор использует строгий контракт, где он легко может ограничить диапазон используемых операторов, полей и значений, передаваемых от клиента.
А динамик линк это полный гуляй-вася.
Автор выбрал такой подход, где его код уже находится в самом удобном для валидации входящих параметров контексте, в то время как динамик линк на входе имеет карт-бланш, а на выходе уже готовый экспрешн.
Я так и не понял. В чем там "строгий контракт", если у автора запрос с клиента приходит в виде коллекции "ключ-значение"? Без проверки туда точно так же напихать можно все что угодно. А, впрочем, похер. Если у автора все работает, и ему нравится, то пускай будет, чем плохо-то. Вон, у фронтендеров на каждый чих по стопятьсот разных фреймворков которые делают одно и то же - и небо на землю от этого не падает :)
В целом задум интересен и понятен, но есть небольшой вопрос: какова цена в плане производительности, если мы на каждый запрос будет собирать финальный предикат? Понятное дело что это будет мизером на фоне самого запроса в БД, но всё же -- насколько?
С рефлексией, без кеша, код пока больше подходит как учебный для объяснения. Но хотелось бы увидеть решение вообще без рефлексии, кодо-генерация.
Что в первом, что во втором вариантах будет проблема с тем, что мы динамически собираем запрос, это означает что от вызова к вызову он будет разным и не будет закэширован на стороне бд. Во втором варианте ещё не будет чёткого контракта у фронта о том а какие фильтры вообще есть для данного эндпоинта, плюс в запросе может быть фильтр по связанной сущности, например по имени автора.
Гибкая фильтрация EFCore с помощью Expression