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

IQ>>>Чтобы упрощать структуру кода, там где это может быть полезно... не?
IQ>·>Если в классе все методы статические, то какая именно польза от класса? Можно просто использовать namespace или что-то подобное.
IQ>Да класс превращается в старый добрый сишный модуль.
С глобальными переменными?
Ты так говоришь, как будто это что-то хорошее.

IQ>·>Для чего?
IQ>Если надо выяснить какие сервисы он использует.
В смысле какие сервисы данный метод использует? А ты с какой целью интересуешься?
Если ты пользователь класса, то тебя это не должно заботить, т.к. наличие у тебя объекта означает, что у него можно дёрнуть метод — все зависимости у него будут по определению, т.к. объект сконструирован.
Если ты разработчк класса, то ты можешь использовать только то, что у тебя есть в конструкторе. Никаких неоднозначностей.
Так что давай дальше объясняй что и зачем ты хочешь выяснить.

Вот есть у тебя UserService.getInstance().serveUser(user) — нужен ли тебе для этого вызова HttpContext.Current? Как узнать?
И наоборот. Вот есть у тебя

public void serveUser(User user)
{
// как узнать - есть ли тут у меня доступ к HttpContext?
}

IQ>>>А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечивают, а IDE будет намеренно мешать навигации по коду!
IQ>·>Конечно, когда конструктор вызывается через рефлекию — IDE ничем помочь не может. А уж если XML-кофиги вспомнить...
IQ>Но это же самые любимые техники "наивного DI".
Это "наивный IoC", DI тут не причём.

IQ>·>Синглтоны скрывают структуру зависимостей и порядок инициализации.
IQ>Это хороший аргумент... но часто порядок инициализации не имеет значения. А если инициализация сложная, то я лично поостерегся бы отдавать ее на откуп малознакомому фреймворку.
Неужели лучше отдать на откуп Undefined Behaviour инициализации статиков?