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

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

В тех проектах на которых работаю я (прямо скажем не больших) в этом нет ничего плохого. В прессе я встречаю не малое количество рекоммендаций по использованию функционального stateless стиля. И мой опыт показывает, что это не пустые слова... Конечно это создает определенные проблемы с согласованностью, но эти проблемы сущая ерунда, по сравнению с теми к которым приводят например попытки реализации наивной доменной модели (DDD). Об этом тоже может напишу пост

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

Книжный какой-то пример... в любой реализации сущности сколь ни будь сложнее сортировки пузырьком есть дофига нюансов. И что самое паршивое — таких сущностей тоже дофига. Вы можете упомнить все нюансы во всех проектах за 3-6 лет? Или можете описать эти нюансы в названиях методов или комментариях к названиям методов? Имхо это просто невозможно.

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

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

А сколько у вас реализаций UserService.getInstance().serveUser ? У нас одна на 20+ проектов Ей более 6 лет и второй не будет я вас уверяю.

·>И наоборот. Вот есть у тебя
·>

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

Ну что-то пример совсем не бей лежачего в BL вообще не должно быть явного использования HttpContext. Все данные должны быть собраны на уровне получения запроса в web controller. А все системные данные текущего пользователя должны находиться в текущем контексте или это будет HttpContext в случае web или CallContext в случае win. Бизнес логика об этом ничего не должна знать.

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

Да я знаю.

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

В простых stateless случаях я не вижу в этом проблемы. В подходе ряды плюсов — не надо ничего описывать, не надо изучать нюансы сторонних фреймворков, не надо давать пояснений и ждать подвохов.