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

IQ>·>Ликбез. Ты глубоко заблуждаешься, что просто использование статических методов означает stateless стиль. Это stateless стиль только в том случае, если нет никакого глобального состояния (да вообще никакого состояния нет, ибо _state_less_), а значит результат такого метода зависит _только_ от его аргументов.
IQ>Да конечно. Отсутствие глобального состояния важный факт.
К чему ты вообще упомянул stateless которого у тебя нет, да и не было никогда?

IQ>·>Да, stateless стиль — благо, но в этом топике я этого не видел, только ламерские Context.Current.
IQ>А вы думаете DI фреймворки как-то по другому работают???
_Могут_ работать по-другому.

IQ>·>Кстати, объекты и нестатические методы тоже бывают stateless — иммутабельные классы например.
IQ>·>Короче, stateless и static — совершенно независимые непересекающиеся понятия.
IQ>Обратного я и не утверждал
И как твой ServiceLocator.GetCurrentUserInfo согласуется с твоей любовью к stateless?

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

IQ>·>Суть в том, что у тебя класс получается более изолированным модулем, который легко понять и проще править независимо, а не просто сборищем малосвязанных методов, которые случайно попали в один файл.
IQ>Это все рекламный мусор. Модуль не класс, а то что он вдруг станет сколь ни будь более изолированным, собери я все зависимости в конструкторе, вообще ниоткуда не следует. На rsdn полно топиков о трудности создания api годного качества.
Как не следует? Если ты будешь использовать только те зависимости, которые есть в конструкторе, то он будет изолирован от всего остального.

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

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

IQ>Да мне повезло, мне не нужно создавать и поддерживать универсальный user-решатор на все случаи жизни и для всех, всех, всех проектов. Наивные коллеги-разработчики хотели сделать такой, но очевидные последствия необходимости тестирования всех систем (коих три десятка) после любого изменения охладили их неопытный пыл, я считаю это своей заслугой.
Какой универсальный? Не нужен мне универсальный. Ты о чём?

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

IQ>>>Все данные должны быть собраны на уровне получения запроса в web controller. А все системные данные текущего пользователя должны находиться в текущем контексте или это будет HttpContext в случае web или CallContext в случае win. Бизнес логика об этом ничего не должна знать.
IQ>·>И как это выражается и контролируется на уровне кода?
IQ>А как это вообще может быть проконтролировано? Только само-дисциплина и код-ревью.
Так уже не раз намекнул — компилятором, с помощью DI+CI.

IQ>Что за ужосы??? Какие камменты? ServiceLocator.GetCurrentUserInfo или
А можно увидеть как выглядит класс ServiceLocator?

IQ>можно вручную создать SysUserService и дернуть нужный метод.
Как выглядит конструктор SysUserService? и где он возьмёт HttpRequest, например? Из тумбочки?

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

IQ>>>·>Неужели лучше отдать на откуп Undefined Behaviour инициализации статиков?
IQ>>>В простых stateless случаях я не вижу в этом проблемы.
IQ>·>Простые случаи ВНЕЗАПНО становятся сложными. Да, в проектах на выброс пиши как хошь — пофиг.
IQ> Или десятилетия не становятся. И в данном конкретном случае не станут. Впрочем вы натолкнули меня на мысль, поэтому вот имхо неплохой аргумент за DI — фреймворки будут все более абстрагировать логику в модулях и рано или поздно фокусы со static и local context вроде бы должны перестать работать. Но вот что странно, подобный подход был в ранних application server в конце 90х (не знаю как обстоят дела с azure) но вот мы до сих пор пишем веб приложения в которых доступны и http запросы и static и local context.
Ну да, действительно, сейчас вон системы и на коболе есть, и работать не перестало. Зачем писать хороший, удобный в поддержке код, когда можно тупо говнокодить?

IQ>·>Но я предпочитаю не участвовать в проектах на выброс.
IQ>Ох... видать мало бизнес логики вам пришлось запилить на своем веку... иногда на выброс идут целые проекты, потому что юзеры не смогли/не захотели разбираться в софте, который для них создало начальство и саботировали внедрение.
Да как было, конечно, раньше, потом набрался опыта.

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

IQ>>>не надо изучать нюансы сторонних фреймворков, не надо давать пояснений и ждать подвохов.
IQ>·>Для DI не нужны фреймворки, нужны только мозги.
IQ>А вот это ведь напрямую связано с темой моего поста Вы вообще с чем не согласны та?
С критикой DI и CI и предлагаемыми альтернативами в виде глобальных переменных в надежде на "подарок".