Здравствуйте, IQuerist, Вы писали:

IQ>>>>>·>Короче, stateless и static — совершенно независимые непересекающиеся понятия.
IQ>>>>>Обратного я и не утверждал
IQ>>>·>И как твой ServiceLocator.GetCurrentUserInfo согласуется с твоей любовью к stateless?
IQ>>>Нда... а у меня оказывается не вульгарный ServiceLocator, а кошерный Ambient Context...
IQ>·>Оппа. Класс называется ServiceLocator, но это не Service Locator. Клёво чё, жоб секьюрити себе обеспечиваешь?
IQ>Честно нет... я искренне не ожидал, что одинаковые вещи могут по разному называться и по разному оцениваться. Для меня это честно было сюрпризом. Но в мутной теме обязаны быть грязные хаки надо лишь поискать.
Ничего не понял. Тема не мутная, похоже муть у тебя в голове. ServiceLocator и Ambient Context вещи не одинаковые, вообще ничего общего.
Ambient Context это хипстерская обёртка для обеспечения более вменяемого использования глобальных переменных.
А Service Locator это фактически такая мапа [serviceId -> serviceImplementation], называемая Registry. Притом сама мапа может протягиваться как через те же глобальные переменные (и даже с использованием Ambient Context), через DI, тупо через арументы метода или ещё как.

IQ>·>Но не важно. Контекст — это состояние. На вопросик-то ответь.
IQ>Состояние у бизнес-операции. Ее обработка создает все нужные контексты и раздает используемым модулям.
Причём тут бизнес-операция? Это вообще не в тему. Смотрим что ты написал:
"и с десяток совершенно очевидных хелперных stateless методов типа: GetBoringItemById". Вот как такой метод может быть stateless? Как мне доводилось видеть, сигнатура такого метода типично
public BoringItem GetBoringItemById(long id)
или у тебя другие варианты?
Покажи как ты видишь этот метод сделать stateless. Ему как минимум нужен borrowed DbConnection и активный TransactionContext, а ещё, бывает, какой-нибудь security context и audit recorder.