Комментарии 4
На схеме 5 вариантов :)
Окружающий контекст — это очень и очень плохая идея:
Выводы:
- Появляются неявные зависимости. Ты в общем случае не знаешь от чего зависит твой код и как его запустить в новом кейсе
- Резко увеличивается связанность кода. Появляется некоторый Service (или Resource) Locator, через который ты получаешь связь абсолютно разных модулей
- Как следствие — невозможность нормального тестирования
- Полная магия с определением контекста в том или ином потоке, в том или ином месте. Неявные, сложные ошибки. Особенно если где то используется Tpl
Выводы:
- О повторном использование, юнит тестирование, гибкости и дешёвом рефакторинге такого кода можно забыть.
- Этот вид зависимости больше похож на наркотическую.
Может, как и любой паттерн, окружающий контекст нужно использовать для решения только подходящих проблем, когда применение паттерна уменьшает сложность?
Вот в этой статье про Entity Framework описывается применение окружающего контекста (как мне кажется, абсолютно логичное).
Вот в этой статье про Entity Framework описывается применение окружающего контекста (как мне кажется, абсолютно логичное).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Паттерны внедрения зависимостей. Часть 2