Денис Цветцих - LINQ Expressions: искусство запрашивать данные
Vložit
- čas přidán 23. 05. 2024
- Ближайшая конференция - DotNext 2024, 10 - 11 сентября, Москва + online
Подробности и билеты: jrg.su/x2GKnA
- -
Запросов на чтение данных в разы больше, чем запросов на их изменение. При этом логика фильтрации может меняться с течением времени. Поэтому важно уметь инкапсулировать правила для фильтрации в специальных обертках, а также комбинировать их как между собой, так и с правилами без оберток.
Доклад - о том, как решить эту задачу при помощи современной реализации паттерна «Спецификация» с использованием LINQ Expressions и с какими подводными камнями можно столкнуться при его реализации. Денис рассказал и о наиболее удобных для использования библиотеках, в которых «Спецификация» уже реализована, в том числе как можно сделать ее c использованием новых фич EF Core 7 или Source Generators.
Кроме того, спикер продемонстрировал выбор наиболее удобного и эффективного способа фильтрации по вложенным коллекциям. И показал, как автофильтр помогает бороться с рутиной фильтрации.
Скачать презентацию с сайта DotNext - jrg.su/G7rqMq
#linq - Věda a technologie
Интересно, есть ли отличия от этого же доклада на другой конференции, который выложили 3 месяца назад?)))
Денис до этого тоже на двух разных конференциях с одним и тем же докладом про модульный монолит выступал
Отличный доклад, просмотрел на 2 раза. Зачастую в больших проектах забивают на все эти вещи и делают кучу экстеншен методов на все случаи жизни )
Но это не правильно. Правильный подход описан тут
Интересный разговор, но 90% времени автор рассказывал про костыли и как обойти то или иное ограничение.
Спецификация не особо прижилась даже в самом DDD, тк это как правило рид сторона приложения.
Если же есть некое бизнес правило в рамках которого надо проверить какие то данные, то это либо определяется либо на уровне контракте репозитория или доменного сервиса. Спецификация в этом случае - это вопрос совсем другого слоя (апп или инфраструктура).
Менять эти спецификации также нужно будет при изменении требований, как и обычные лямбды.
В чем смысл всего этого accidental complexity и кто его будет поддерживать?
Лично я строго против данного паттерна и подхода.
Фильтр накладывается "НА...", а это подразумевает логическую операцию "И", а вот "UNION" - это ИЛИ...
Это философский аспект и его часто на факультетах информатики, кибернетики и прочих математик не преподают - жаль