Стандартный паттерн использования DbContext в ASP.NET Core это его иньекция туда где он нужен. Сам DbContext при этом принято регистрировать как scoped (так по умолчанию).

В принципе, не могу вспомнить, чтобы у меня случались какие-то проблемы с этим, но не оставляет ощущение, что в этом заложено что-то недоброе. Scoped компонент в ASP.NET Core это объект глобальный для всего HTTP request, т.е. со всеми возможными граблями глобального объекта (сторонние эффекты).

Я однажды предложил вместо DbContext инжектить его фабрику, но у всех, разумеется, тут же полыхнуло, типа: "Еще наши прадеды инжектили DbContext, а ты тут собрался оскорбить их память и могилы обосс..ть". Вот мне и интересно узнать - кто-нибудь делает инъекцию DbContext не напрямую?

Нет, если фабрика будет работать через тот же DI, то при выходе из скоупа все что она насоздавала будет тоже диспозиться. В принципе, есть-то опция, чтобы регистрировать DbContext как transient, но на существующем проекте это как бы слишком уж глобаное изменение и делать его рисковано.

Да как бы нет, любой объект DI действительно принадлежить какому-либо скоупу, но ведь если он зареган как transient, то для каждой инъекции создается новый инстанс, так что никакой глобальности - каждый зависимый объект получит свой собственный экземпляр зависимости.

Все что создается через ДиАй диспозится автоматически когда диспозится его скоуп. Это же испокон веков во всех контейнерах так. Сам проверь, убедись, если хочешь. И транзиент тоже.

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

Врят ли. Кстати, по производительности. Если ты сделаешь подряд запросы, типа


То объект тебе вернет один и тот же, но у тебя все равно будет два запроса к БД, т.е. кеша все равно нет.


Всегда нравилась эта его фича. Особенно с инжектом Func<IService> - там даже фабрики в большинстве случаев не надо.

Практически все сценарии работы с ним в ASP.NET - "запросил -> изменил -> сохранил", а потом он уже становится не нужен. Если какая-то десктопная аппликуха, то там вполне может быть и по другому, но в вебе само по себе все считай транзитивное из-за его stateless натуры.

Почему?

1) Сервис А использует контекст и вызывает сервис Б, сервис Б тоже использует контекст, но не знает (и не должен ничего знать) про сервис А, т.к. инкапсуляция, single responsibility и все такое. И, понятно, что он тем более не знает что там перед ним сервис А с контекстом натворил. Запросто можно нарваться на какие-нибудь неожиданности.

2) Сервис А использует контекст и вызывает сервис Б. Сервис Б использует контекст и сохраняет свои изменения. Если сервис А перед вызовом Б внес свои изменения и еще не сохранял, то сервис Б сам того не ведая сохранит и их тоже и это как-то некрасиво.

В общем, глобальный объект это глобальный объект, от того что его назвали красивым словом "scoped" он глобальным быть не перестал, разве что его "глобальность" несколько ограничили.

Я хочу (или, лучше сказать, мне это кажется более правильным), чтобы каждый отдельный сервис, вызываемый в пределах скоупа, получал свой собственный экземпляр контекста, а не фигачил все свои изменения/сохранения в общий, рискуя нарваться на какие-либо конфликты с другими сервисами, вызываемыми в этом же скоупе.

Я бы лучше сказал "в рамках вызова сервиса". Потому что если несколько взаимосвязанных запросов раскиданы по нескольким сервисам, то это вообще какой-то говнодизайн, нарушается весь loose coupling. А если в рамках одного вызова сервиса, то какие проблемы - получи контекст, сделай там хоть стопятьсот запросов и изменений, потом все одним разом сохрани - обычный Unit of work. И вот, кстати цикл работы с UoW (загрузи -> измени -> сохрани) это по сути отдельная логическая транзакция (не зря ведь его назвали "unit"). И существует очень общее правило: "при завершении (коммит/роллбек) транзакция забывает свое состояние". Т.е. любая транзакция никогда не должна использовать данные полученные в другой транзакции. А шейринг контекста между сервисами это правило нарушает.

Тут, на самом деле, есть еще подводный камень, про который надо помнить - даже транзитивный объект живет все время жизни скоупа в котором он создан. В ASP.NET это проблем не создает, т.к. сами скоупы все короткоживущие, но, скажем, в каком-нибудь десктопном приложении это следует учитывать.

hVostt,

Да лично я-то никогда на практике со scoped data context проблем не имел, но просто вижу возможность их поимения. Потому что, повторюсь, scoped это по сути нечто глобальное, к чему имееет доступ все что только можно. А что-то глобальное это всегда возможность выстрелить себе в ногу. Это-то мне и не нравится.

Вот, смотри, такой, допустим, воображаемый сценарий.

1) Сервис А добавляет в контекст запись о покупке
2) Сервис А вызывает сервис Б чтобы вычислить НДС
3) Сервис А добавляет НДС в запись о покупке
4) Сервис А сохраняет изменения через SaveChange

Выглядит все нормально. Но вот. Я как разработчик сервиса А не знаю, да и знать не хочу как внутри устроен сервис Б. И поэтому я в душе не ведаю, что сервис Б для чего-то и сам вызывает SaveChanges (кто его там знает, может он какой-то аудит вызовов в базу пишет) - и он в этом вполне прав, потому что его тоже не должно волновать, что и как я перед его вызовом делал. И при таком сценарии между п.2 и п.3 в БД окажется некорректная запись (с ценой, но без НДС), которую, между прочим, какой-то другой запрос может прочитать, т.к. другой запрос будет в другом скоупе и у него будет "чистый" датаконтекст.

С т.з. правильного использования UoW я пока вижу только такой вариант, чтобы над всеми этими сервисами ставить какой-то сервис-оркестратор, который будет заниматься только тем, что вызывать нужные сервисы, а потом одним махом делать общий "коммит" в виде вызова SaveChanges.

Чего же тут правильного, если я вызывая какой-то сервис, который писал вообще не я, должен всегда думать: "а не сохранит ли он мне то моё, что я еще пока что сохранять еще не хочу". Это вообще нарушение всех принципов модульности и инкапсуляции.

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


Почему левый? Обычный сервис из проекта, который мне для моих целей из моего сервиса нужен. Или же уже сервисам нельзя вызывать другие сервисы?

Это еще очень напоминает известную замороку со вложенными транзакциями в SQL. Там из-за этого, если ты хочешь внутри SP делать транзакцию приходится ставить проверки не находишься ли ты уже внутри транзакции. По крайней мере, когда-то это было так.

Ну и где там SaveChanges происходит? В конце вызова контроллера? Смахивает на костыль какой-то.

Как решает?

Вот. Теперь смотри. Я пишу компонент (сервис). Меня заботит только то, что этот сервис должен делать то, для чего он предназначен. Меня вообще не волнует и не должно волновать, кто, как, и в каком сценарии его использует. А теперь, откуда мне знать, что тот, кто его использует, или тот, кто использует того, кто его использует действительно сохраняет изменения.

Если все три вызова должны быть одной транзакцией, значит их надо явно объединять в одну транзакцию. При твоем подходе, получается, что SaveChanges надо вообще куда-то в middleware выносить.

А, кстати, в твоем примере кода, если ничего-таки не бахнет, то кто SaveChanges будет делать?

Т.е. инжектить DbContext в контроллер?

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

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

Тоже плохо. Потому что IUnitOfWork это все равно DAL, а не BL.


Сервис, работа которого зависит от других сервисов, про которые он даже ничего не знает?

Отвлечемся вообще от БД и контекста. Допустим, у меня стек вызов сервисов А->B>C->D и оказывается, что поведение сервиса D зависитот того, что делал сервис A перед тем как вызвал B. Это уже не модульное приложение будет, а какая-то адова лапша.

А если он где-то в фильтре используется, или в middleware? Да и, как я уже писал, вызывать DAL прямо из контроллера это уже сама по себе хрень какая-то. А по-хорошему, если что-то шарится между разными компонентами, должно быть иммутабельно. Поскольку дбконтекст таковым не является, то от этого можно вполне ожидать какой-нибудь беды.

А я и не сказал, что напрямую использовать. Он может использоваться через какой-либо сервис BL.


Контроллер отвечает за трансляцию HTTP-запроса в вызов сервиса(ов) BL и трансляцию ответа от BL в HTTP-ответ. Знать что-то о том, что лежит ниже BL он не имеет права.