Это не DAL, это UOW. UOW может реализовывать не только SaveChanges в DbContext-а, но выполнять любые другие завершающие операции: отправка сообщений в очередь, инициация событий, сохранение данных в другие репозитории.

Мыслить рамками, что DbContext это абсолютно вся работа с данными что есть -- вредно.
Это не так.



Именно является. Как я уже сказал, это UOW. Проблема в твоих рассуждениях, что ты за DbContext видишь какой-то маленький кусочек, но не видишь остального.

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

Всё верно.

Просто со времён развития идеи fat controller is evil, люди ушли в другую крайность, которая ещё хуже, чем жирные контроллеры.

Именно контроллер отвечает за правильную организацию обработки запроса. От слова контроллер же!

И что? Не вижу никаких проблем. В фильтре или в миддлеваре вообще нужно избегать работы с DbContext. И действовать через разумные абстракции.

Ну фиг знает, может у тебя фильтр для записи в БД лога запросов.
И отсюда растут ноги у проблемы :)

Конечно, так делать нельзя, DbContext для таких задач не предназначен.



А он и не знает. Не вижу никаких противоречий

ПОГОДИ!
А если _этот сервис_ в тайне от тебя в БД что-то пишет?
Что тогда?
При чём тут тогда DbContext? :)

И что он там такого может _изменить_, что повлияет на тебя? Я просто не понимаю. Это что вообще он там может такого сделать?



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

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


Надо как-то немного конкретней выделить проблему.

Ну давай тогды IMemoryCache тоже сделаем транзиентным

Как я уже говорил, от общего DbContext в скоупе есть реальный профит. Именно так он рекомендуется к использованию. Теоретически это тоже объясняется одним предложением: DbContext это UOW.

Какие-то надуманные и высосанные из пальца проблемы, якобы кто-то другой в мой контекст влезет и что-то там сломает на практике совершенно не подтверждаются. Проект, который построен на EF уже по факту обладает довольно высокой связностью.

Давай я пример ещё приведу.
У тебя есть приложение на EF с контекстом.
Ты решил добавить себе фоновые службы, вынес в отдельное сервисное приложение, как полагается.
Взял хенгфаер.

Теперь зырь: https://github.com/sergezhigunov/Hangfire.EntityFrameworkCore

Намекаю на то, что задачи Hangfire никак не пересекаются с задачами твоего DbContext.
Значит это другой контекст.

И ещё намекаю, раз у тебя в рамках одного DbContext реализуются совершенно не связанные задачи и разнесённая на пару парсеков логика, значит у тебя явно нарушение SRP и ты пытаешься вылечить зрение через ж-пу :)

fkthat,

В упор не вижу, как нарушается инкапсуляция DbContext-а. Это ведь итак уже абстракция. Итак контракт. Давай ещё каждый отдельный компонент ЕДИНОГО приложения будет содержать свой драйвер БД, свой пул соединений, свою файловую систему, каждому классу по отдельной плашке памяти и т.д. и т.п. :)

Вот сколько мы дискутируем, я так и не увидел ни одного хоть отдалённо приближенному к границам реальности кейса, где была обнаружена проблема, которую ты решаешь :)



А почему нет? Вот у меня добрый десяток _изолированных_ компонентов используют DbContext в одном HTTP запросе. Мне что на обработку запроса десяток соединений к одной и той же БД создавать?

Инженерия это прежде всего компромисс. Все шаблоны и принципы -- это борьба со сложностью, а не религия.

продвинутые пацаны юзают CQ(R)S и на эту тему не парятся :)

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

Мы же как-то живём с вилками и ножами, не смотря на всю их смертельную угрозу :)



Ну так пул как бы не бесконечный ресурс :)
Например, под нагрузками 100-200K rpm и выше, ресурсами не разбрасываются, особенно с необъяснимым выхлопом.

Так типа ты вообще не тащишь никакой XxxxxContext :)

Эти правила как раз применимы к HTTP-запросу. Дальше дробить, это уже ебантяйство какое-то :)




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

fkthat,

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

Не забываем, что кроме уменьшения связанности, нужно думать о хорошей связности.

Когда у тебя в проекте 100500 интерфейсов на каждую херню, это уже не смешно.

так у тебя для публики команды и запросы
никто в репу не ходит, есть она там и или нет.

насчёт uow, по-хорошему нужен, но не обязателен, если структура логики позволяет