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

J>>>·>И какой тут смысл создавать инстанс UserService? Чем UserService.Save со статическим методом хуже?
J>>>Вообщем-то можно и статические методы исспользовать.
IQ>·>Зачем тогда классы вообще существуют?..
IQ>Чтобы упрощать структуру кода, там где это может быть полезно... не?
Если в классе все методы статические, то какая именно польза от класса? Можно просто использовать namespace или что-то подобное.

IQ>·>И ещё получается такой некий твой "class Settigs", который зависит от всего и все от него зависят.
IQ>·>Собственно IoC-контейнер позволяет этим хоть как-то рулить. Синглтоны однозначно в топку.
IQ> Старая история, IoC-контейнер выполняет роль статического конструктора, но адепты верят, что так они чем-то по особенному рулят.
Если выбирать между IoC-контейнером и signletones я однозначно выберу первое. Но простой DI лучше обоих.

IQ>·>Нет. Просто передаёшь всех менеджеров в конструкторе.
IQ>·>UserService(UserProfileManager, AcitvityManager, SomethingManager, ...)
IQ>·>Да, конструктор _может_ получиться с тучей аргументов, но зато сразу видно что именно требуется для функционирования данного класса, тебе не нужно читать код каждого отдельного метода чтобы выяснить а что же этот конкретный метод в этой ветке if-условия решил вытянуть из глобального Context.Current.
IQ>Это иллюзия, код каждого конкретного метода читать все равно придется
Для чего?

IQ>·>И, более того, это всё проверяется на этапе компиляции, все зависимости обеспечены, плюс IDE помогает с навигацией по коду, find usages, go to declaration и прочим.
IQ>А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечивают, а IDE будет намеренно мешать навигации по коду!
Конечно, когда конструктор вызывается через рефлекию — IDE ничем помочь не может. А уж если XML-кофиги вспомнить...
Синглтоны скрывают структуру зависимостей и порядок инициализации.

IQ>·>Далее, если у тебя таки получается класс у которого очень много зависимостей это сразу явно видно по его конструктору. Это просто значит что данный класс превращается в Универсальный Всемогутор (https://en.wikipedia.org/wiki/God_object) и требуется рефакторинг: пилишь компоненты по зависимостям так, чтобы уменьшить максимальную валентность графа зависимостей.
IQ>Какая красота, люди ведь не замечают, что полдня работают с одним файлом кол-во строк которого перевалило за несколько тыс. И что найти метод без средств студии уже просто нереально
В проекте где хотя бы за 5к файлов/классов так и есть.

IQ>А так — глянул конструктор и все понятно А то, что всю эту сервисную обвязку при рефакторинге скорее всего придется переносить во новые классы. Ну это фигня не упаримся.
В этом хотя бы IDE отлично помогает. В отличии от клубка синглтонов.

IQ>Нам работу компилятора выполнять не в тягость!
Какую работу компилятора ты собрался выполнять?

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

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

Да класс превращается в старый добрый сишный модуль.

IQ>>·>Нет. Просто передаёшь всех менеджеров в конструкторе.
IQ>>·>UserService(UserProfileManager, AcitvityManager, SomethingManager, ...)
IQ>>·>Да, конструктор _может_ получиться с тучей аргументов, но зато сразу видно что именно требуется для функционирования данного класса, тебе не нужно читать код каждого отдельного метода чтобы выяснить а что же этот конкретный метод в этой ветке if-условия решил вытянуть из глобального Context.Current.
IQ>>Это иллюзия, код каждого конкретного метода читать все равно придется
·>Для чего?

Если надо выяснить какие сервисы он использует.

IQ>>·>И, более того, это всё проверяется на этапе компиляции, все зависимости обеспечены, плюс IDE помогает с навигацией по коду, find usages, go to declaration и прочим.
IQ>>А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечивают, а IDE будет намеренно мешать навигации по коду!
·>Конечно, когда конструктор вызывается через рефлекию — IDE ничем помочь не может. А уж если XML-кофиги вспомнить...

Но это же самые любимые техники "наивного DI".

·>Синглтоны скрывают структуру зависимостей и порядок инициализации.

Это хороший аргумент... но часто порядок инициализации не имеет значения. А если инициализация сложная, то я лично поостерегся бы отдавать ее на откуп малознакомому фреймворку.

Здравствуйте, 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 инициализации статиков?

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

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 случаях я не вижу в этом проблемы. В подходе ряды плюсов — не надо ничего описывать, не надо изучать нюансы сторонних фреймворков, не надо давать пояснений и ждать подвохов.

Здравствуйте, 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 не нужны фреймворки, нужны только мозги.

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

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

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

Да конечно. Отсутствие глобального состояния важный факт.

·>Да, stateless стиль — благо, но в этом топике я этого не видел, только ламерские Context.Current.

А вы думаете DI фреймворки как-то по другому работают???

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

Обратного я и не утверждал

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

Ну хватит вам уже извиняться за DI

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

Я показал, что "собирание зависимостей в конструкторе" имеет такую же иллюзорную ценность как и "улучшение тестируемости" решения.

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

Это все рекламный мусор. Модуль не класс, а то что он вдруг станет сколь ни будь более изолированным, собери я все зависимости в конструкторе, вообще ниоткуда не следует. На rsdn полно топиков о трудности создания api годного качества.

·>Попробуй — понравится, примеры кода я публиковал в этом топике.

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

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

Но она практически не меняется, т.к. ее контракт сильно ограничен и определен в рамках конкретного проекта. И все расширения тоже локальны для конкретных проектов. Это просто хороший api для очень конкретной ниши.

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

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

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

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

HttpContextService, DbContextService, CacheContextService, LoggingContextService — имхо как раз первые признаки наивного DI.

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

А как это вообще может быть проконтролировано? Только само-дисциплина и код-ревью.

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

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

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

Что за ужосы??? Какие камменты? ServiceLocator.GetCurrentUserInfo или можно вручную создать SysUserService и дернуть нужный метод.

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

Это я что ли вспомнил про "Конечно, когда конструктор вызывается через рефлекию — IDE ничем помочь не может. А уж если XML-кофиги вспомнить..."?

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

Или десятилетия не становятся. И в данном конкретном случае не станут. Впрочем вы натолкнули меня на мысль, поэтому вот имхо неплохой аргумент за DI — фреймворки будут все более абстрагировать логику в модулях и рано или поздно фокусы со static и local context вроде бы должны перестать работать. Но вот что странно, подобный подход был в ранних application server в конце 90х (не знаю как обстоят дела с azure) но вот мы до сих пор пишем веб приложения в которых доступны и http запросы и static и local context.

·>Но я предпочитаю не участвовать в проектах на выброс.

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

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

Долг за которым никогда не придут — подарок...

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

А вот это ведь напрямую связано с темой моего поста Вы вообще с чем не согласны та?

Здравствуйте, 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 и предлагаемыми альтернативами в виде глобальных переменных в надежде на "подарок".

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


IQ>Что за ужосы??? Какие камменты? ServiceLocator.GetCurrentUserInfo
Я вот тут хорошее объяснение окнопал на пальцах и с картинками почему этот твой подход говно:
http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/
Ну и вывод совпадающий с моим:

The compiler can offer both consumers and producers so much help when Constructor Injection is used, but none of that assistance is available for APIs that rely on Service Locator.

Собственно, прежде чем отвечать на предыдущий пост ознакомься с этой статьёй и пиши возражения по делу, если есть.

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

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


IQ>>Что за ужосы??? Какие камменты? ServiceLocator.GetCurrentUserInfo
·>Я вот тут хорошее объяснение окнопал на пальцах и с картинками почему этот твой подход говно:
·>http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/
·>Ну и вывод совпадающий с моим:

The compiler can offer both consumers and producers so much help when Constructor Injection is used, but none of that assistance is available for APIs that rely on Service Locator.

·>Собственно, прежде чем отвечать на предыдущий пост ознакомься с этой статьёй и пиши возражения по делу, если есть.

Нда... Как говорит народная мудрость лучше всего бандиты решают те проблемы которые сами и создают В посте Seemann создал инвалидное решение, огреб проблем и доблестно все порешал с помощью constructor injection! Какую же проблему он решил? А оказывается OrderProcessor.Process(Order order) внутри использует IOrderValidator! Но зачем явно передавать его в конкретный метод, если можно где-то там, за ширмой неявно затаскивать его через конструктор в DI? Ведь достаточно будет посмотреть конструктор, и метод инициализации всех сервисов системы и все сразу станет понятно! Не забывайте это делать при вызове каждого метода сервиса и пожалуйста отслеживайте все время изменения, которые вносят ваши коллеги. Кроме валидатора, в OrderProcessor.Process можно затащить много любопытных вещей, а вы, по api об этом даже не узнаете Это очень удобно.

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

IQ>>>Что за ужосы??? Какие камменты? ServiceLocator.GetCurrentUserInfo
IQ>·>Я вот тут хорошее объяснение окнопал на пальцах и с картинками почему этот твой подход говно:
IQ>·>http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/
IQ>·>Ну и вывод совпадающий с моим:

The compiler can offer both consumers and producers so much help when Constructor Injection is used, but none of that assistance is available for APIs that rely on Service Locator.

IQ>·>Собственно, прежде чем отвечать на предыдущий пост ознакомься с этой статьёй и пиши возражения по делу, если есть.
IQ>Нда... Как говорит народная мудрость лучше всего бандиты решают те проблемы которые сами и создают В посте Seemann создал инвалидное решение, огреб проблем и доблестно все порешал с помощью constructor injection! Какую же проблему он решил? А оказывается OrderProcessor.Process(Order order) внутри использует IOrderValidator!
Не только IOrderValidator, но и IOrderCollector, а потом со временем добавление IOrderShipper.

IQ>Но зачем явно передавать его в конкретный метод,
Потому что вызовов этого конкретного метода может быть много по всему коду, а вызововы конструктора обычно постоянны.

IQ>если можно где-то там, за ширмой неявно затаскивать его через конструктор в DI? Ведь достаточно будет посмотреть конструктор,
Зачем тебе его смотреть? Если у тебя есть ссылка на OrderProcessor — то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует.
Если у тебя такой ссылки нет, то смотри wiring и найди добавь эту ссылку к себе. Если не получится — значит что-то у тебя не хвататет в зависимостях, протаскивай как надо куда надо, а не надейся на глобальные переменные.

IQ>и метод инициализации всех сервисов системы и все сразу станет понятно!
Что такое "метод инициализации всех сервисов системы"?

IQ>Не забывайте это делать при вызове каждого метода сервиса и пожалуйста отслеживайте все время изменения, которые вносят ваши коллеги. Кроме валидатора, в OrderProcessor.Process можно затащить много любопытных вещей, а вы, по api об этом даже не узнаете Это очень удобно.
Да, удобно. А ты предлагаешь всё затаскивать через параметры метода? А в месте вызова этого метода они откуда возьмутся? Из тумбочки?

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

Подумал, если DI, IoC, Singleton сравнивать с реальной жизнью.
Представим что у нас есть 1000 новостей, которую мы хотим рассказать городу.
* Singleton — вешаем доску с новостями и каждый житель города, сам решает когда ему подойти и прочитать что он хочет.
* DI — мы попомним, чем интересуется каждый из жителей и когда у нас появляются новости, мы бежим в нужную квартиру доложить о новостях.
* IoC — у каждого жителя включен телефон и мы вещаем в тел. новости пачками иногда доставляя их не тем кто их ждет.

Проблема IoC в том что нам сложно/дорого провести нормальную связь к каждому из жителей.
Проблема DI в том что нам надо помнить кому что надо знать и постоянно бегать к жителям домой. (а они гады иногда спят, едят, гуляют где-то в вне квартиры).
Проблема Singleton в том что возле доски может собраться большая толпа людей и они могут приходить в неправильной последовательности как нам хотелось бы.

Но, если взглянуть на жизнь со стороны, то решать проблемы с Singleton проще/дешевле/лучше, чем другими методами:
городские телефоны у нас глючат(бывает такое что слышем в трубке соседей)/IoC/, доставляя неудобства; почтальоны, те кто снимают показания с щетчиков, раздают повестки приходят когда нас нет дома/DI/, теряют на это драгоценно время всего общества. Но, когда мы приходим в налоговую или к врачу, всегда можно взять талончик и узнать приблизительно время, когда можно подойти или записаться на определенно время(хз, может еще не везде так, но упустим политику)/Singleton/, тут у нас страдает(или вообще нет), только отдельно взятый юнит.

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

J>Подумал, если DI, IoC, Singleton сравнивать с реальной жизнью.
Лучше не надо. Надо взять какой-то код и попробовать переписать в разных стилях. Можешь показать тут какой-нибудь код, а я могу попробовать дать идеи как его переписать на DI.

Но если тебе так хочется, вот моя аналогия.

J>Представим что у нас есть 1000 новостей, которую мы хотим рассказать городу.
J>* Singleton — вешаем доску с новостями и каждый житель города, сам решает когда ему подойти и прочитать что он хочет.
Это скорее всего большой открытый базар-толкучка. Ибо доска read only, а синглтоны — ВНЕЗАПНО меняются. Особенно такие как HttpContext.CurrentRequest.

J>* DI — мы попомним, чем интересуется каждый из жителей и когда у нас появляются новости, мы бежим в нужную квартиру доложить о новостях.
Это что-то типа заказа по интернету. Задекларировал "нужны штаны и ведро картошки", тебе их привозят домой с помощью специально организованной службы доставки (wiring code), тебя как клиента не интересует как служба работает. Служба доставки знает что кому нужно и организует логистику чтобы всем всё доставлять.

J>* IoC
Ты наверное имеешь в виду Service Locator.
SL и DI — это паттерны, которые реализуют принцип IoC — когда не ты сам идёшь за тем, что тебе надо, а тебе дают то что тебе надо.

J>SL — у каждого жителя включен телефон и мы вещаем в тел. новости пачками иногда доставляя их не тем кто их ждет.
Что-то вроде специализированных магазинов. Ты знаешь где продаются штаны и туда ходишь.

J>Проблема IoC в том что нам сложно/дорого провести нормальную связь к каждому из жителей.
Проблема — идёшь в магазин, а он закрыт, или товар заканчивается и ты остаёшься без штанов, или там жуткая очередь.

J>Проблема DI в том что нам надо помнить кому что надо знать и постоянно бегать к жителям домой. (а они гады иногда спят, едят, гуляют где-то в вне квартиры).
Проблема — нужна компьютерная грамотность у населения. Зачем жамкать какие-то кнопки у шайтан-машины, когда можно как мой дед выйти вон на ту площать и купить/продать ведро картошки.

J>Проблема Singleton в том что возле доски может собраться большая толпа людей и они могут приходить в неправильной последовательности как нам хотелось бы.
Проблема — пришел за штанами в знакомое место, а там офигенная очередь, или продавец ими больше не торгует, или на обед решил сходить. Ещё надо хорошо помнить и знать куда за чем ходить.

J>Но, если взглянуть на жизнь со стороны, то решать проблемы с Singleton проще/дешевле/лучше, чем другими методами:
J>городские телефоны у нас глючат(бывает такое что слышем в трубке соседей)/IoC/, доставляя неудобства; почтальоны, те кто снимают показания с щетчиков, раздают повестки приходят когда нас нет дома/DI/, теряют на это драгоценно время всего общества. Но, когда мы приходим в налоговую или к врачу, всегда можно взять талончик и узнать приблизительно время, когда можно подойти или записаться на определенно время(хз, может еще не везде так, но упустим политику)/Singleton/, тут у нас страдает(или вообще нет), только отдельно взятый юнит.
signleton подходит для небольших городов. В городах побольше уже образуются несколько базаров, пришел в один — ничего нет, поехал в другой. А где-то очереди, а где-то пусто, а где-то густо. И сложно угадать что когда и какого качества сможешь купить.

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

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

Нда... а у меня оказывается не вульгарный ServiceLocator, а кошерный Ambient Context...

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

IQ>>Нда... Как говорит народная мудрость лучше всего бандиты решают те проблемы которые сами и создают В посте Seemann создал инвалидное решение, огреб проблем и доблестно все порешал с помощью constructor injection! Какую же проблему он решил? А оказывается OrderProcessor.Process(Order order) внутри использует IOrderValidator!
·>Не только IOrderValidator, но и IOrderCollector, а потом со временем добавление IOrderShipper.

IQ>>Но зачем явно передавать его в конкретный метод,
·>Потому что вызовов этого конкретного метода может быть много по всему коду, а вызововы конструктора обычно постоянны.

Но это еще хуже! Если реализация IOrderValidator, IOrderCollector и IOrderShipper существует одном экземпляре то нафига выносить их из модуля и засорять область приложения. А если их много, то необходимо явно и локально показывать их зависимость от контекста иначе логика размазывается.

IQ>>если можно где-то там, за ширмой неявно затаскивать его через конструктор в DI? Ведь достаточно будет посмотреть конструктор,
·>Зачем тебе его смотреть? Если у тебя есть ссылка на OrderProcessor — то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует.

Компилятор гарантирует? Мне казалось DI работает исключительно в динамике. И потом, если разные варианты поведения, то мне надо четко указать, какое использовать, если поведение одно — зачем вообще выносить его за границы модуля? Впрочем я знаю ответ... — "для unit тестов". Вот так убогие фреймворки для тестирования порождают архитектурные проблемы.

·>Если у тебя такой ссылки нет, то смотри wiring и найди добавь эту ссылку к себе. Если не получится — значит что-то у тебя не хвататет в зависимостях, протаскивай как надо куда надо, а не надейся на глобальные переменные.

Но мне не надо ничего протаскивать, мне надо локально указать конкретный вариант.

Мое имхо по итогам обсуждения поста:

Ребята это секта... секта свидетелей DI фреймворков, отпочковавшаяся от секты свидетелей TDD. Вообще имхо DI фреймворки появились из за того, что сектантам TDD было необходимо тестировать приватную логику, а по их канонам unit test этого делать нельзя. Поэтому был применен ряд шельмований, приватную логику перекрестили в сервисы вытащили их наружу. Здесь можно вспомнить COM, который решает аналогичные DI фреймворкам задачи, но в те времена не было движения TDD и поэтому COM не стал религией, а остался инфраструктурным решением.

Ни DI ни TDD ничего не гарантируют разработчику, ни от чего не защищают и ни в чем не помогают. Зато гарантированно служат серьезным источником оверхеда. Как же им удается иногда демонстрировать свою полезность? А все элементарно... например код веб систем, можно разделить на две части — бизнес логику и код взаимодействия с системными сервисами UI, DB и т.д. Взаимодействие с системными сервисами разработчику понятно, отлично проработано и имеет долгую историю. Что провоцирует наивные умы, особенно на первых этапах проекта, запихиать бизнес логику прямо в код взаимодействия с системными сервисами. Так создаются шедевры спагетти кода. Что делает TDD? Оно ограничивает — сначала пишем тесты. И тут все верно, в юнит тестах нет взаимодействия с системными сервисами поэтому структуру бизнес логики приходится прорабатывать отдельно от всего т.е. приходится строить архитектуру. Вот и весь трюк. Цена такого подхода — серьезный оверхед (уровень которого зависит от религиозного фанатизма разработчика), потому что бизнес логика гарантированно будет уточнятся и изменяться и тесты придется переписывать, но как мы теперь понимаем, для проработки бизнес логики и построения архитекуры тесты на самом деле лишь полезны, но никак не обязательны.

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

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

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

IQ>·>Потому что вызовов этого конкретного метода может быть много по всему коду, а вызововы конструктора обычно постоянны.
IQ>Но это еще хуже! Если реализация IOrderValidator, IOrderCollector и IOrderShipper существует одном экземпляре то нафига выносить их из модуля и засорять область приложения. А если их много, то необходимо явно и локально показывать их зависимость от контекста иначе логика размазывается.
Пусть одна реализация, это дело не меняет. Пишут эту реализацию другие люди, в другой команде, или это какой-нибудь RPC-интерфейс или ещё что — не важно. В вопросе главное как управлять зависимостями, а не конкретные названия классов/интерфейсов.

IQ>>>если можно где-то там, за ширмой неявно затаскивать его через конструктор в DI? Ведь достаточно будет посмотреть конструктор,
IQ>·>Зачем тебе его смотреть? Если у тебя есть ссылка на OrderProcessor — то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует.
IQ>Компилятор гарантирует? Мне казалось DI работает исключительно в динамике.
Если кажется — крестись, или хотя бы учебники читай. Я же уже ссылку давал на вики, читал? Где там динамика?

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

IQ>·>Если у тебя такой ссылки нет, то смотри wiring и найди добавь эту ссылку к себе. Если не получится — значит что-то у тебя не хвататет в зависимостях, протаскивай как надо куда надо, а не надейся на глобальные переменные.
IQ>Но мне не надо ничего протаскивать, мне надо локально указать конкретный вариант.
Какой конкретный вариант? Забудь множественные имплементации, не в них дело. Дело в том, что "конкретный вариант" тоже откуда-то должен взяться, у него можеть быть специфичный lifespan и у него могут быть свои зависимости.

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

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

DI uber alies, а то что инкапсуляция идет лесом — пофигу?

IQ>>>>если можно где-то там, за ширмой неявно затаскивать его через конструктор в DI? Ведь достаточно будет посмотреть конструктор,
IQ>>·>Зачем тебе его смотреть? Если у тебя есть ссылка на OrderProcessor — то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует.
IQ>>Компилятор гарантирует? Мне казалось DI работает исключительно в динамике.
·>Если кажется — крестись, или хотя бы учебники читай. Я же уже ссылку давал на вики, читал? Где там динамика?

Нда... а вы вообще программированием занимаетесь? "то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует" компилятор по вашему конструирует объекты???

IQ>>И потом, если разные варианты поведения, то мне надо четко указать, какое использовать, если поведение одно — зачем вообще выносить его за границы модуля? Впрочем я знаю ответ... — "для unit тестов". Вот так убогие фреймворки для тестирования порождают архитектурные проблемы.
·>Это далеко не единственный ответ.

Имхо единственный, остальное — отмазы.

IQ>>·>Если у тебя такой ссылки нет, то смотри wiring и найди добавь эту ссылку к себе. Если не получится — значит что-то у тебя не хвататет в зависимостях, протаскивай как надо куда надо, а не надейся на глобальные переменные.
IQ>>Но мне не надо ничего протаскивать, мне надо локально указать конкретный вариант.
·>Какой конкретный вариант? Забудь множественные имплементации, не в них дело. Дело в том, что "конкретный вариант" тоже откуда-то должен взяться, у него можеть быть специфичный lifespan и у него могут быть свои зависимости.

А вот это отличный ответ... проясняет почему разговор идет именно о сервисах. Спасибо. Конечно остается вопрос — почему в виденом мною коде где использовался DI ничего из этого не использовалось... Это конечно не к вам претензия, а к "мейнстриму".

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

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

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

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

·>Но не важно. Контекст — это состояние. На вопросик-то ответь.

Состояние у бизнес-операции. Ее обработка создает все нужные контексты и раздает используемым модулям.

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

IQ>·>Пусть одна реализация, это дело не меняет. Пишут эту реализацию другие люди, в другой команде, или это какой-нибудь RPC-интерфейс или ещё что — не важно. В вопросе главное как управлять зависимостями, а не конкретные названия классов/интерфейсов.
IQ>DI uber alies, а то что инкапсуляция идет лесом — пофигу?
alles же.
Как раз с инкапсуляцией всё гораздо лучше, по сравнению с твоими любимыми глобальными переменными.

IQ>>>Компилятор гарантирует? Мне казалось DI работает исключительно в динамике.
IQ>·>Если кажется — крестись, или хотя бы учебники читай. Я же уже ссылку давал на вики, читал? Где там динамика?
IQ>Нда... а вы вообще программированием занимаетесь? "то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует" компилятор по вашему конструирует объекты???
Компилятор проверяет, что вызов конструктора выполнен с правильными аргументами, обеспечивает невозможность обратиться к методам несконструированного объекта, и защищает доступ к приватным полям классов, не давая доступ к зависимостям, которых у тебя не предусмотрено. Тем самым в рантайме обеспечивает гарантию.

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

IQ>·>Какой конкретный вариант? Забудь множественные имплементации, не в них дело. Дело в том, что "конкретный вариант" тоже откуда-то должен взяться, у него можеть быть специфичный lifespan и у него могут быть свои зависимости.
IQ>А вот это отличный ответ... проясняет почему разговор идет именно о сервисах. Спасибо. Конечно остается вопрос — почему в виденом мною коде где использовался DI ничего из этого не использовалось... Это конечно не к вам претензия, а к "мейнстриму".
Собственно моя претензия в том, что ты лишь на основании своего негативного опыта с говнопроектами в одну кучу всё свалил и раскритиковал. Вместо того чтобы внести ясность, поделиться как же делать правильно, дискредитируешь хорошие техники всякими уничижительными словечками типа Colonoscopy Injection. И так тут сплошное невежество в "мейнстриме", а ты только усугубляешь.