Комплексные запросы при помощи IQueryable и Expression Trees (Dev Labs 2017)

Видео доклада Ивана Кошелева, представленного на онлайн-конференции Dev Labs 2017 (04/03/2017).
Рассматриваются темы:
- Ключевые отличия IQueryable и Expression Trees от IEnumerable и делегатов. Обзор возможностей Expression Trees.
- Композиция IQueryable и Expression Trees для создания сложных запросов из более простых переиспользуемых запросов.
- Безопасная Generic-фильтрация и сортировка с помощью Expression Trees ( DTO - Expression Tree - SQL ).
- Вынесение переиспользуемой логики запросов в Expression Trees. LinqKit.
- Юнит-тестирование сложных запросов. Мок-контексты данных и мок-функции.

[@ИгорьХохлов-ь4ю]

Чувак, отвечаю, я в своем проекте все так е перепишу. Спс.

[@hannimedable]

Как долго выполняются такие запросы? Мне кажется, это работает, до тех пор пока есть время и ресурсы на генерацию отчетов по таким запросам. В случае больших нагрузок, такой подход увы не сработает...

[@sergbo3114]

А что такого в запросах генерируемых ЕФ криминального? Большинство проблем как было сказано связано с неправильным индексированием. Ну если конечно не писать запросы которые разворачиваются в 1000 запросов SQL. А вообще как сказал герой фильма "Мандалорец" : "Не знаешь не говори!" И я не к тому что сомневаюсь в ваших знаниях, а к тому что у вас нет конкретного примера медленных запросов сгенерированных ЕФ. Есть только ключевое слово "кажется". Ну говорил же докладчик что бывают очень редко ситуации что еф не справляется. Сам сталкивался с медленными запросами. Доходило до оптимизации плана выполнения запроса. Но когда бд и систему в целом планировал криворуких хрен, как в моем случае, то никакая оптимизация не помогает. Например у меня разработчик приложения посчитал нифиговой идею фильтровать(выбирать) записи в таблице где их 30 лямов текстом. Причем текст внутри строки. Например "TK512345123.1206" вот 512345123 это номер по которому шла выборка. В итоге не преобразовать поле, ни толком проиндексировать. Не всегда дело в запросах.

[@xDedMopdex]

Как-то бывший тех Лид присек мои порывы писать подобные иерархии IQueriable обосновывая это тем, что при изменении базовых выборок , можно поломать выборки более высоких уровней и даже этого не заметить, а потом долго отлавливать где именно косяк. Что думаете по этому поводу?

[@xDedMopdex]

Если конечно не брать во внимание вариант интеграционных тестов. Мало кто из клиентов на них соглашается

[@sergbo3114]

"Частично запросы генерируются JavaScript`ом." Звучит опасно. Как бы нельзя было туда чет заинжектить с запросом на стороне клиента(браузера) и на бд какойнить делит загнать)

[@timur2887]

Все попытки заменить sql через linq и expression trees так и не достигли успеха, т.к. как ни крути, но описать сложный запрос понятнее и короче, чем в sql c# не может, но эти попытки говорят о том, что новые поколения программистов не сильны в языках запросов и предпочитают все кодить в языке высокого уровня, упуская из виду, что sql разрабатывался именно для работы с множествами и, хотя он очень стар и местами неуклюж, с множествами в нем до сих пор работать гораздо удобнее.

[@timur2887]

Какой ужас эти Expression Trees, совершенно нечитаемы.. на порядок проще понять/написать sql запрос, еще и короче выйдет.