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

IQ>·>С глобальными переменными?
IQ>·>Ты так говоришь, как будто это что-то хорошее.
IQ>В тех проектах на которых работаю я (прямо скажем не больших) в этом нет ничего плохого. В прессе я встречаю не малое количество рекоммендаций по использованию функционального stateless стиля. И мой опыт показывает, что это не пустые слова... Конечно это создает определенные проблемы с согласованностью, но эти проблемы сущая ерунда, по сравнению с теми к которым приводят например попытки реализации наивной доменной модели (DDD). Об этом тоже может напишу пост
Ликбез. Ты глубоко заблуждаешься, что просто использование статических методов означает stateless стиль. Это stateless стиль только в том случае, если нет никакого глобального состояния (да вообще никакого состояния нет, ибо _state_less_), а значит результат такого метода зависит _только_ от его аргументов. Да, stateless стиль — благо, но в этом топике я этого не видел, только ламерские Context.Current.
Кстати, объекты и нестатические методы тоже бывают stateless — иммутабельные классы например.
Короче, stateless и static — совершенно независимые непересекающиеся понятия.

Да и причём тут DI?

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

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

IQ>·>Вот есть у тебя UserService.getInstance().serveUser(user) — нужен ли тебе для этого вызова HttpContext.Current? Как узнать?
IQ>А сколько у вас реализаций UserService.getInstance().serveUser ? У нас одна на 20+ проектов Ей более 6 лет и второй не будет я вас уверяю.
Да какая разница? Ну пусть одна (но помни, что она ВНЕЗАПНО в течение 6 лет всяко разно меняется разными людьми). Ответь на вопрос.

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

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

IQ> Ну что-то пример совсем не бей лежачего в BL вообще не должно быть явного использования HttpContext.
Ок. Ну пусть не HttpContext, пусть DbContext или как тут выше по топику "Context.Current.Scope.Resolve<IUserManager>". Это что-то изменит?

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

Ты наверное просто пишешь в коде

public void serveUser(User user)
{
// Мамой клянус!!!
   doSomething(user, Context.Current.Stuff);
}

А дальше плагин к компилятору находит все эти комментарии и проверяет?

IQ>>>Но это же самые любимые техники "наивного DI".
IQ>·>Это "наивный IoC", DI тут не причём.
IQ> Да я знаю.
Ну и зачем опять терминами жонглируешь?

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

IQ>В подходе ряды плюсов — не надо ничего описывать,
Это тупо технический долг.

IQ>не надо изучать нюансы сторонних фреймворков, не надо давать пояснений и ждать подвохов.
Для DI не нужны фреймворки, нужны только мозги.