Использование единого IoC Container'a в рамках HTTP-запроса между Web API и OWIN Middleware

Чем this.GetCacheManager() лучше параметра cacheManager, переданного к конструктор?

Или открытого свойства CacheManager (хоть это и антипаттерн)?

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

А с использованием IoC надо будет убрать из конструктора параметр cacheManager и добавить другой, который вам действительно нужен.

Или, если cacheManager закопан в инфраструктуре — сделать NullCacheManager. Но его в таком случае придется делать в любом случае, хоть с IoC, хоть без.

Так как я выше писал контекст запроса и есть внутренние потроха фреймворка.

Совершенно не обязательно. Текущий пользователь? Роли текущего пользователя? Права и привилегии текущего пользователя? Это все весьма независимо от фреймворка (сугубо бизнесовых примеров тоже есть, но для них надо предметную область объяснять).

Per-request кеш на мой взгляд это не что иное как например Bag (или другая коллекция на уровне реквеста). Так зачем тогда придумывать велосипед…

Чтобы отвязаться от конкретной реализации.

Я могу выполнять вот такой extension метод на контроллере this.GetCacheManager()

Можете. И теперь вам надо протащить контроллер везде, где вам нужен этот кэш — в том числе, в прикладную область, если вдруг в ней есть кэши.

Давайте на примере.

class SchemaController: ApiController
{
  private readonly IMetadataProvider _metadataProvider;

  public SchemaController(IMetadataProvider metadataProvider)
  {
    _metadataProvider = metadataProvider;
  }

  public Schema Get(string version)
  {
    return _metadataProvider.Get(version);
  }
}

Все прекрасно, все работает. Теперь мне надо внутрь конкретной реализации IMetadataProvider добавить кэширование (и, чтобы не возиться с инвалидацией, сделать кэширование продолжительностью в запрос пользователя, потому что на этом промежутке данные считаются консистентными). Чтобы использовать ваш подход, мне надо в Get передать либо сам CacheManager (наружу просочились детали реализации), либо this (и тогде кроме утекания реализации я еще получу зависимость провайдера от WebAPI). Если же я просто останусь в рамках DI, я могу либо вкинуть в конструктор провайдера нужный мне ICacheManager, либо вообще кэшировать данные в собственных полях реализации, а провайдер просто привязать к запросу. И, что характерно, оба этих варианта совершенно прозрачны для приведенного мной кода — он даже не знает, что мы сделали оптимизацию. Если потом мы передумаем и уберем оптимизацию, или, наоборот, сделаем кэш более долгоживущим — код-пользователь останется неизменным.

Если же я отдаю управление жизненным циклом IoC контейнеру, то это уходит за пределы программной инфраструктуры веб приложения.

И это прекрасно, потому что теперь мы можем выполняться не только в контексте веб-приложения.

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

А в случае с DI вы просто сделаете другую реализацию для ICacheManager, от которого зависит реализация IMetadataProvider, или же — еще проще — поменяете длину жизненного цикла самого провайдера.

А вот с использованием IoC контейнера данный факт будет не совсем очевидным.

Ну так пользователю (коду) и не надо знать, что там внутри кэширование. А для реализации все зависимости очевидны.

Вы даже не будете точно знать в какой именно момент выполняемого transaction script вы будете брать те или иные данные, что в некоторых случая может приводить к блокировкам, притом иногда к deadlock.

Говорю же — не больше 1 пользователя онлайн (либо разработчик, либо заказчик). В исключительных ситуациях — целых два :)

Но вы здесь говорите о меняющихся требованиях, что наводит на мысль, что вы все-таки хотите это все поддерживать.

Я говорю не о поддержке — а о ситуации, когда код непредсказуемо переписывается каждую неделю. Тут любой новый слой лишь увеличивает работу по переписыванию.

Вы не думали, что сам факт использования ORM, должен быть не доступен вашему Web приложению?

Это почему вдруг?

что вам даст идемпотентность? ничего…

Идемпотентность дает возможность многократно накатывать операцию до тех пор, пока она наконец не пройдет. Это позволяет обойтись без распределенной транзакции.

Если из системы А в Б ушло 500 попугаев — то:

1. создается запись в А об ушедших попугаях, транзакция завершается;
2. создается запись в Б о пришедших попугаях, транзакция завершается;
3. создается запись в А о успешном создании записи в Б, транзакция завершается.

Шаги 2-3 повторяются в фоне до тех пор пока в системе А есть запись о передаче попугаев в Б, но нет отметки об успехе.

Принципиальное отличие от распределенной транзакции — в том, что ни одна из записей не блокируется на неопределенное время.