Денис Цветцих - LINQ Expressions: искусство запрашивать данные

Ближайшая конференция - DotNext 2024, 10 - 11 сентября, Москва + online
Подробности и билеты: jrg.su/x2GKnA
- -
Запросов на чтение данных в разы больше, чем запросов на их изменение. При этом логика фильтрации может меняться с течением времени. Поэтому важно уметь инкапсулировать правила для фильтрации в специальных обертках, а также комбинировать их как между собой, так и с правилами без оберток.
Доклад - о том, как решить эту задачу при помощи современной реализации паттерна «Спецификация» с использованием LINQ Expressions и с какими подводными камнями можно столкнуться при его реализации. Денис рассказал и о наиболее удобных для использования библиотеках, в которых «Спецификация» уже реализована, в том числе как можно сделать ее c использованием новых фич EF Core 7 или Source Generators.
Кроме того, спикер продемонстрировал выбор наиболее удобного и эффективного способа фильтрации по вложенным коллекциям. И показал, как автофильтр помогает бороться с рутиной фильтрации.
Скачать презентацию с сайта DotNext - jrg.su/G7rqMq
#linq

[@dsboldyrev]

Мне кажется или доклад на половину скопирован с Максим Аршинов - Деревья выражений в enterprise-разработке?

[@user-dt6wc3sr5s]

Интересно, есть ли отличия от этого же доклада на другой конференции, который выложили 3 месяца назад?)))

[@user-ge4ds5ii8p]

Денис до этого тоже на двух разных конференциях с одним и тем же докладом про модульный монолит выступал

[@vladlenbulatov1022]

Фильтр накладывается "НА...", а это подразумевает логическую операцию "И", а вот "UNION" - это ИЛИ... Это философский аспект и его часто на факультетах информатики, кибернетики и прочих математик не преподают - жаль

[@Fikusiklol]

Интересный разговор, но 90% времени автор рассказывал про костыли и как обойти то или иное ограничение. Спецификация не особо прижилась даже в самом DDD, тк это как правило рид сторона приложения. Если же есть некое бизнес правило в рамках которого надо проверить какие то данные, то это либо определяется либо на уровне контракте репозитория или доменного сервиса. Спецификация в этом случае - это вопрос совсем другого слоя (апп или инфраструктура). Менять эти спецификации также нужно будет при изменении требований, как и обычные лямбды. В чем смысл всего этого accidental complexity и кто его будет поддерживать? Лично я строго против данного паттерна и подхода.

[@polarbar780]

Отличный доклад, просмотрел на 2 раза. Зачастую в больших проектах забивают на все эти вещи и делают кучу экстеншен методов на все случаи жизни ) Но это не правильно. Правильный подход описан тут