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 прямо из контроллера это уже сама по себе хрень какая-то. А по-хорошему, если что-то шарится между разными компонентами, должно быть иммутабельно. Поскольку дбконтекст таковым не является, то от этого можно вполне ожидать какой-нибудь беды.