Декоратор это паттерн, если реализовывать в лоб, то это довольно уродливое решение.
Поэтому лучше говорить про аспекты.



Я так понимаю, ты с кешем работаешь исключительно через декораторы? :)

es )



Ну тогды ладно :)
У нас проектах кеш не только для чистых данных используется, но и много для чего ещё.
Хотя, глядя на единственный CRUD проджект, который у нас есть небольшой, там и правда не используется..

Ну вот как раз на случай обмазать кешем, аудитом и прочей фигнёй)

На кеше много чего интересного можно реализовать :)
Как бы, и зачастую проще заюзать IMemoryCache, чем городить город из декораторов.
Понимаю, что есть динамик кастл и прочие прикольные штуки, но это не молоток, чтобы теперь все-все задачи были гвоздями. Где-то уместно, где-то не очень.

Ну вообще, чаще всего уместно использовать IDistributedCache, это всё очень вариативно, чтобы всегда можно было решать декоратором. Поэтому декоратор это как шаблонный паттерн для массивного применения.

Точечно пилить декоратор это злостный оверхед.

1) он итак уже отделён в отдельном месте, называется это место IMemoryCache :)
2) вообще он должен знать, так как без нормальной инвалидации такой кеш приносит больше вреда, чем пользы

Я всё равно не поддерживаю идеалистические подходы, без зрелого и осознанного понимания что делаешь в каждом конкретном случае. Всё делать через декоратор -- такое себе утверждение.

Как бы вот есть отвёртка, есть шуруповёрт, есть пневматика. Для каждого случая, для каждой задачи больше подходит свой инструмент. Говорить, что теперь всё херачим шуруповёртом и гвозди забиваем -- ну хз )))

Декоратор это структурный паттерн, это для организации структуры приложения.

Нельзя решить все проблемы и задачи работы с кешем структурой.
Ибо там дальше может дойти до маразма, и код будет предтсавлять собой десятиэтажную абстракцию, ради решения простой задачи. Это будет медленно работать, жрать ресурсы, а разработчики вынуждены писать тонну оверхеда, ради экономии одной строчки кода.

Ты лучше расскажи как решаешь проблему с инвалидацией кеша на декораторах :)

Почему условное-то? Вполне себе конкретное :)

Декоратор никоим образом не оказывает влияния на взаимодействие компонентов.
А медиатор это конкретное решение для обеспечения взаимодействие.
И я видел злоупотребление тем же медиатором.
Как видел злоупотребление декоратором.

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

Ну вот! К вопросу о transient-ном DbContext, может не надо ломать контекст, чтобы не защащаться от злостных изменений?


Как бы если в голове пусто, то хоть привяжи ко лбу пенопласт, помешать разбить лоб это не поможет.

Ну ты хоть покажи каких проблем ты там ожидаешь поиметь.
Я в упор не понимаю о каких проблемах ты говоришь.
Может ты с ними столкнулся в реале?

Потому что сейчас это похоже на проблему преждевременной эякуляции оптимизации.

Займусь этим когда в этом возникнет необходимость.
Например, глобальная переменная может создать мне проблем для покрытия тестами -- там и сделаю то, что нужно.

А просто так заниматься бессмысленной работой смысла не вижу.

Твой пример -- яркий. Ты себе что-то вообразил и борешься с этим. Тысячи людей пользуют DbContext в скоупе и он так используется по примерам майкрософт, и всё хорошо.

У тебя вдруг с какого-то перепугу в голове стало плохо. Переклинило чтоли?
Ну если у тебя дофига свободного времени, и заняться больше нечем, переноси DbContext из скоупа в транзиент.

Работа настолько же бессмысленная, насколько и бесполезная и глупая. Но если тебе так спокойней, делай кто мешает