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

·>Здравствуйте, 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, тупо через арументы метода или ещё как.

Читаем талмудъ:

https://smarly.net/dependency-injection-in-net/di-catalog/di-patterns/ambient-context

Ambient Context сходный по структуре с анти-паттерном Service Locator, который я опишу в главе 5. Разница состоит в том, что Ambient Context предоставляет экземпляр только одной, строго типизированной зависимости, в то время как Service Locator предположительно должен обеспечить экземпляры для каждой зависимости, которую вы можете запросить. Различия являются тонкими, так что убедитесь, что вы полностью понимаете, когда следует применять Ambient Context, прежде чем сделать это. Если вы сомневаетесь, выберите другой DI паттерн.

Хипстер — Марк Симан

Кстати там же про Thread Local Storage и HttpContext

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

GetBoringItemById не имеет состояния, состояние "DbConnection и активный TransactionContext" предоставляются ему внешними сервисами. Да в моем случае этот сервис глобальный (как и loggingContext). Ваш пример конечно интересен, хотя на мой взгляд никаких явных TransactionContext, security context и audit recorder и т.д. в DAL быть не должно — не тот уровень абстракции Они все же должны быть в высокоуровневом сервисе и это имхо очевидный маркер того, что в случае GetBoringItemById DI используется неверно.