Паттерны внедрения зависимостей. Часть 2

[VolCh]

На схеме 5 вариантов :)

[tmteam]

Окружающий контекст — это очень и очень плохая идея:

• Появляются неявные зависимости. Ты в общем случае не знаешь от чего зависит твой код и как его запустить в новом кейсе
• Резко увеличивается связанность кода. Появляется некоторый Service (или Resource) Locator, через который ты получаешь связь абсолютно разных модулей
• Как следствие — невозможность нормального тестирования
• Полная магия с определением контекста в том или ином потоке, в том или ином месте. Неявные, сложные ошибки. Особенно если где то используется Tpl

Выводы:

• О повторном использование, юнит тестирование, гибкости и дешёвом рефакторинге такого кода можно забыть.
• Этот вид зависимости больше похож на наркотическую.

[mike_ama]

Может, как и любой паттерн, окружающий контекст нужно использовать для решения только подходящих проблем, когда применение паттерна уменьшает сложность?

Вот в этой статье про Entity Framework описывается применение окружающего контекста (как мне кажется, абсолютно логичное).

[tmteam]

В указанной вами статье, автор, в разделе «The Bad», пишет примерно тоже самое, что и я. При этом он не освещает проблем тестирования.

Уменьшение сложности в сильносвязанном коде с магическим оттенком — илюзорно. Только по количеству строчек кода.