powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Dependency injection. Как скрыть внутренние реализации ?
58 сообщений из 58, показаны все 3 страниц
Dependency injection. Как скрыть внутренние реализации ?
    #39285407
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет.

Как я понимаю реализация паттерна DI такова (на примере Asp Net Mvc), что есть один контейнер и в нем зарегистрированы все все все сущности.
Как тогда реализовать DI в ситуации,когда у нас в DLLке есть интернальные классы, имеющие смысл внутри только этой DLLки ?

Если у нас имеется лишь единый контейнер, куда мы вынуждены зарегистрировать сотню наших интернальных классов, то там свалка вообще получится да и мы тогда отдаем свои интернальные классы наружу.
Неужели нужно внутри этой библиотеки организовывать свой внутренний DI что ли ? Да еще скрещивать его с внешним DI, ведь класс доступный публично придется регистрировать в обоих контейнерах. Это прям почти какой-то "containers hell" получается :)

Есть какое-то решение для данной проблемы, или нету проблемы вообще ?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39285611
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotekКак тогда реализовать DI в ситуации,когда у нас в DLLке есть интернальные классы, имеющие смысл внутри только этой DLLки ?

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

Но! Если у разработчика DI головного мозга, когда каждый чих делается через зависимость, то эту болезнь надо лечить, а не искать «решение».

Желательно обходиться без DI там где это можно — максимально. Если что-то делается только внутри одного модуля и не выходит наружу, то в таких случаях лучше вообще избегать использования контейнера.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39285619
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttНо! Если у разработчика DI головного мозга, когда каждый чих делается через зависимость, то эту болезнь надо лечить, а не искать «решение».

Желательно обходиться без DI там где это можно — максимально. Если что-то делается только внутри одного модуля и не выходит наружу, то в таких случаях лучше вообще избегать использования контейнера.
+100500
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39285642
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttНо! Если у разработчика DI головного мозга, когда каждый чих делается через зависимость, то эту болезнь надо лечить, а не искать «решение».


А как иначе быть ? Если не DI будет через конструктор (чаще всего) инжектить зависимости то кот ?
Хардкодить создание классов по месту использования ? А как же юнит-тестирование ?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39285679
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotek, Вы конкретный пример приведите того, что за "интернальные", почему их надо инжектить, почему без этого нельзя покрыть юнит-тестами?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39285702
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANA,

Ну пожалуйста. Чисто абстрактный пример.

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
internal class ClassSlow: ICalculator
    {
        private readonly string _someData1;
        private readonly string _someData2;
        public ClassSlow(string someData1, string someData2)
        {
            _someData1 = someData1;
            _someData2 = someData2;
        }

        public int GetResult() { return 1; } 
    }

    internal class ClassFast: ICalculator
    {
        public int GetResult() { return 2; }
    }

    public class Service: IService
    {
        private readonly ICalculator _slowCalculator;
        private readonly ICalculator _fastCalculator;

        public void Add5ToCalculatorResult(bool isFast)
        {
            if (isFast)
                return _fastCalculator.GetResult() + 5;
            else
                return _slowCalculator.GetResult() + 5;
        }
    }



Либа которая может рассчитать медленно но точно, или быстро но не очень точно (абстрактный пример же).
Внешнему миру нужен доступ к IService. Сам сервис зависит от реализаций ICalculator, о которых внешнему миру просто не интересно знать (а может даже и не нужно).

Очевидно помещать создание этих классов в Service не правильно потому, что
- это сильно свяжет его с этими классами. В частности ему придется знать про некие параметры someData1, someData2.
- не получится протестить этот класс, передав ему мок-стаб вместо этих ICalculator.

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

Просто стало интересно как правильно конфигурировать интернальные классы в DI контейнере, создал темку.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39285808
Сон Веры Павловны
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotekskyANA,
Ну пожалуйста. Чисто абстрактный пример.

Чисто абстрактный класс вместо интерфейса + factory method - и DI в данном случае не нужен.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39285834
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotekПоэтому получается, что фактически да, нужно использовать DI на каждый чих.

Не получается. Приводить такой пример, для которого оправдано применение DI в подтверждение тезиса «на каждый чих», это как доказывать что молотком забивать гвозди — совершенно нормально.

Решать конечно тебе. Но скажу сразу, за повальное применение DI где надо и где не надо, особенно в закрытых модулях как часть внутренней реализации -- по головке тебя за это не погладят. Будешь в джуниорах ходить до старческих штанов. Учись кодить правильно, включай голову!
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39285837
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotekПросто стало интересно как правильно конфигурировать интернальные классы в DI контейнере, создал темку.

В модулях вместо DI, можно использовать классическую реализацию паттерна Стратегия. Возможно, тебе как раз таки не калькулятор тут нужен, а сам метод вычисления, при чём это не зависимость, а явное требование передать конкретный алгоритм для вычисления (быстрый, медленный, унылый, весёлый...). Ты явно не на том сосредоточился.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286034
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot hVostt]ProBiotek Желательно обходиться без DI там где это можно — максимально.
а можно подробнее? просто это такое максималистское заявление. не могли бы вы объяснить почему так категорично?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286047
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
winsky!а можно подробнее? просто это такое максималистское заявление. не могли бы вы объяснить почему так категорично?

Что конкретно в этом утверждении не нравится? Давайте обсуждать не характер заявлений (то, как вам кажется), а предметно.

Я могу пояснить, что за всё нужно платить. Если DI позволяет решить малой кровью некоторые проблемы в архитектуре, то злоупотребление им может нанести больше ущерба, чем пользы. Это относится к любым инструментам и методикам.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286049
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttwinsky!а можно подробнее? просто это такое максималистское заявление. не могли бы вы объяснить почему так категорично?

Что конкретно в этом утверждении не нравится? Давайте обсуждать не характер заявлений (то, как вам кажется), а предметно.

Я могу пояснить, что за всё нужно платить. Если DI позволяет решить малой кровью некоторые проблемы в архитектуре, то злоупотребление им может нанести больше ущерба, чем пользы. Это относится к любым инструментам и методикам.
я не говорил, что не нравится. я сказал, что утверждение слишком громкое. я имею в виду, что я могу вообще обойтись без DI и это будет именно "максимально".
и я спрашиваю очень предметно, какой вред может принести использование паттерна?
т.е. - в каких случаях его применение оправданно, а в каких нет?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286084
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
winsky!я сказал, что утверждение слишком громкое.

ну так и ваш комментарий можно оценить, как слишком злобное, показывающее, что вам категарически что-то не нравится, что почему-то в следующем комментарии вы также категорически отрицаете :) т.е. такой дискурс ни к чему хорошему не приведёт, суждения о суждениях. давайте лучше предметно.

winsky!какой вред может принести использование паттерна?

употребление DI приводит к новому уровню абстракции, и это усложняет понимание системы. если программист начинает злоупотреблять DI, то прочитать его код становится сложной задачей, а понять — ещё сложнее. стоит ли говорить, к чему это в итоге приводит? об этом хорошо написано у первоисточника, автора этого принципа Роберта Мартина.

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

вы вот, сможете ответить на этот вопрос?

winsky!т.е. - в каких случаях его применение оправданно, а в каких нет?

если сможете ответить на мой вопрос, то он в принципе должен содержать ответ на этот. а если нет, то лучше вам обратиться к специальной литературе и попрактиковаться в реальных приложениях.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286149
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
эм... давайте определимся. мы говорим о dependency inversion principle или о паттерне dependency injection?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286200
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

Вы тоже в своих ответах весьма абстрактны. не привели ни одного примера (а я привел) когда DI не нужен и КАК его заменить, чтобы классы остались достаточно unit-тестируемы (т.е. без тестирования всей кучей с их зависимостями). Как создавать описанные Вами стратегии и как их передавать в класс, который в них нуждается (кто или что этим будет заниматся, если не DI). Это может быть интересно. Может потом действительно можно будет взять на вооружение.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286304
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotekПоэтому получается, что фактически да, нужно использовать DI на каждый чих. Везде, даже во внутренних классах библиотек.
Уточните пожалуйста, где в Вашем примере используется DI "во внутренних классах библиотек".
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286341
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANA,

Ну при конфигурировании IService нужно будет регистрировать его зависимости ICalculator.
Потом DI их либо автоматически отрезолвит, либо мы можем сами через метод Resolve<>. Но это происходит вне указанной в примере системы. Т.е. IService должен уже получать на вход сконструированные классы.

Вопрос был "привести пример внутренних классов, которые нужно конфигурировать в DI и почему их нельзя тестить без этого".
Отвечаю (выше это уже написал), если конструировать ICalculator внутри IService это вынудит IService знать про некие параметры someData1, someData2. А также не позволит его нормально протестировать передав моки-стабы вместо ICalculator.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286480
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotek, короче hVost Вам выше уже ответил: каждая DLL сама себя регистрирует в контейнере.

А пример Ваш толком ничего не показывает, уж извините :)
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286519
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
winsky!эм... давайте определимся. мы говорим о dependency inversion principle или о паттерне dependency injection?

Мы говорим об DI, который в свою очередь является формой IoC в реализации. Смысл говорить о принципах не применительно к коду? Так вернёся к вопросу. Для чего нужен DI?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286532
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotekhVostt,

Вы тоже в своих ответах весьма абстрактны. не привели ни одного примера (а я привел) когда DI не нужен и КАК его заменить, чтобы классы остались достаточно unit-тестируемы (т.е. без тестирования всей кучей с их зависимостями). Как создавать описанные Вами стратегии и как их передавать в класс, который в них нуждается (кто или что этим будет заниматся, если не DI). Это может быть интересно. Может потом действительно можно будет взять на вооружение.

Я очень конкретно ответил. Примеры кода я приведу, когда вы опишете конкретную проблему. Если вы переживаете, что в контейнере слишком много зависимостей — и что лучше будет, если у каждого модуля будет свой личный контейнер — не стоит этого делать и не стоит переживать. Проблемы не существует.

Паттерн Стратегия описан очень хорошо на всех языках, гуглится на раз. Зачем я буду пыжиться и демонстрировать вам свои авторские способности по описанию паттернов, если это уже давно сделано и легко доступно? Паттерн Статегия зачастую гораздо лучше решает некоторые задачи, чем DI. Скажу по секрету, есть ещё и другие архитектурные паттерны. Стоит их изучить. И у вас будет много других гораздо более интересных вопросов, чем беспокойство о количестве зависимостей в контейнере.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286546
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

Паттерны я знаю, и кто такие GOF )
Вопрос был в том, как инжектить эти интернальные стратегии - суть зависимости в класс. Ну в принципе я понял Вашу идею о том, чтобы регистрировать все в одном большом контейнере.
Просто подумал о том что раз есть классы internal то как это должно правильно соотносить с DI. Ладно может проблемы нету, ок.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286933
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotekhVostt,

Паттерны я знаю, и кто такие GOF )

Разве?
https://ru.wikipedia.org/wiki/Банда_четырёх «Ба́нда четырёх» (кит. трад. 四人幫, упр. 四人帮, пиньинь: Sìrén bāng, палл.: Сы жэнь бан) — термин (фактически идеологический ярлык), используемый в официальной китайской пропаганде и историографии для обозначения группы высших руководителей Коммунистической партии Китая, выдвинувшихся в ходе Культурной революции 1966—1976 годов, являвшихся наиболее приближенными к Мао Цзэдуну лицами в последние годы его жизни.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39286999
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЕвгенийВ,

Ну я именно это и имел ввиду. А Вы других GOF что ли знаете еще ? )
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287056
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotekЕсли у нас имеется лишь единый контейнер, куда мы вынуждены зарегистрировать сотню наших интернальных классов, то там свалка вообще получится да и мы тогда отдаем свои интернальные классы наружу.Ну и в чём проблема? Ты всё равно из других сборок не сможешь запросить штатным способом internal-типы из контейнера, потому что компилятор выдаст ошибку. Чудеса рефлекшена не рассматриваем.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287072
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КЧудеса рефлекшена не рассматриваем.
как это DI и без чудес рефлекшна ?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287253
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttwinsky!эм... давайте определимся. мы говорим о dependency inversion principle или о паттерне dependency injection?

Мы говорим об DI, который в свою очередь является формой IoC в реализации. Смысл говорить о принципах не применительно к коду? Так вернёся к вопросу. Для чего нужен DI?
еще раз, на доступном языке, че за DI? :D
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287258
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
winsky!еще раз, на доступном языке, че за DI? :D

Т.е. ответа не будет? Хех, ну и ладенько.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287259
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttwinsky!эм... давайте определимся. мы говорим о dependency inversion principle или о паттерне dependency injection?

Мы говорим об DI, который в свою очередь является формой IoC в реализации. Смысл говорить о принципах не применительно к коду? Так вернёся к вопросу. Для чего нужен DI?
ну и, используя ваше же тактику:
я не знаю, для чего нужен DI (чтобы тут не имелось в виду). объясните мне пожалуйста.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287263
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttwinsky!еще раз, на доступном языке, че за DI? :D

Т.е. ответа не будет? Хех, ну и ладенько.
нет, конечно.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287265
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
winsky!я не знаю, для чего нужен DI (чтобы тут не имелось в виду). объясните мне пожалуйста.

Конкретизируйте свои вопросы. Это я хотел услышать от вас, что такое DI и для чего он нужен. Вы ответа не знаете, но зачем-то ввязались в спор.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287271
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttwinsky!я не знаю, для чего нужен DI (чтобы тут не имелось в виду). объясните мне пожалуйста.

Конкретизируйте свои вопросы. Это я хотел услышать от вас, что такое DI и для чего он нужен. Вы ответа не знаете, но зачем-то ввязались в спор.
а я и не утверждал, что знаю. я просто молодой джун, вот пытался использовать dependency injection, наткнулся на ваш посо, где вы утверждаете, что нужно максимально избегать использования dependency injection, максимально для меня - это не использовать вовсе. но конкретезировать вы почему-то отказались (ну фразы "этого объяснять не нужно" и т.д.), начав забрасывать меня контрвопросами, достаточно неумными, кстати, мне это даже как джуну видно. уж простите.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287526
ioc_ioc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно так, все записхать сразу в конечном проекте. Есть свои плюсы - тестирование. Но это не модульность. Хотя слои нарезаны, слабая связность (за исклювением конечного проекта) обеспечена
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287528
ioc_ioc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А можно так. Модульность тут рулит просто безгранично. И прикурить на этом не хило (или перейти на Java Spring)
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287531
ioc_ioc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хвост, кажется об этом говорил, вначале топика
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39287534
ioc_ioc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttЕсли что-то делается только внутри одного модуля и не выходит наружу, то в таких случаях лучше вообще избегать использования контейнера.

можешь опытом поделиться, плиз. я пока плохо себе это представляю.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288026
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМы говорим об DI, который в свою очередь является формой IoC в реализации.DI может существовать и быть полезным без IoC, не так ли?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288345
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КhVosttМы говорим об DI, который в свою очередь является формой IoC в реализации.DI может существовать и быть полезным без IoC, не так ли?

http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288353
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей К,

Сейчас с DI происходит примерно тоже самое, что с ООП много лет назад. Доходит до истерии, на собеседованиях главенствующее положение занимают вопросы по DI. Многие разработчики тотально и категорически впадают в крайности по принципу «масло кашей не испортишь», ко всем классам лепят тень-интерфейсы и регают в контейнере. Идёт война контейнеров. В общем, ещё пару годков и уляжется. Трупы склюют вороны.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288517
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttАлексей Кпропущено...
DI может существовать и быть полезным без IoC, не так ли?

http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html
мне показалось, может, но Алексей задал риторический вопрос..
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288521
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttАлексей К,

Сейчас с DI происходит примерно тоже самое, что с ООП много лет назад. Доходит до истерии, на собеседованиях главенствующее положение занимают вопросы по DI. Многие разработчики тотально и категорически впадают в крайности по принципу «масло кашей не испортишь», ко всем классам лепят тень-интерфейсы и регают в контейнере. Идёт война контейнеров. В общем, ещё пару годков и уляжется. Трупы склюют вороны.
может быть. но говорить, что DI нужно избегать где только можно, я бы не стал. как и ООП кстати :D
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288525
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
winsky!hVosttАлексей К,

Сейчас с DI происходит примерно тоже самое, что с ООП много лет назад. Доходит до истерии, на собеседованиях главенствующее положение занимают вопросы по DI. Многие разработчики тотально и категорически впадают в крайности по принципу «масло кашей не испортишь», ко всем классам лепят тень-интерфейсы и регают в контейнере. Идёт война контейнеров. В общем, ещё пару годков и уляжется. Трупы склюют вороны.
может быть. но говорить, что DI нужно избегать где только можно, я бы не стал. как и ООП кстати :D
DI контейнеры нужно применять в 3 случаях.
1. если используешь внешние сервисы
2. если делаешь поддержку плагинов
3. если пишешь книгу или статью в блог и хочешь показаться офигенно крутым чуваком
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288528
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЕвгенийВwinsky!пропущено...

может быть. но говорить, что DI нужно избегать где только можно, я бы не стал. как и ООП кстати :D
DI контейнеры нужно применять в 3 случаях.
1. если используешь внешние сервисы
2. если делаешь поддержку плагинов
3. если пишешь книгу или статью в блог и хочешь показаться офигенно крутым чуваком
аминь
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288575
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
winsky!hVosttАлексей К,

Сейчас с DI происходит примерно тоже самое, что с ООП много лет назад. Доходит до истерии, на собеседованиях главенствующее положение занимают вопросы по DI. Многие разработчики тотально и категорически впадают в крайности по принципу «масло кашей не испортишь», ко всем классам лепят тень-интерфейсы и регают в контейнере. Идёт война контейнеров. В общем, ещё пару годков и уляжется. Трупы склюют вороны.
может быть. но говорить, что DI нужно избегать где только можно, я бы не стал
А вот в Stack Overflow избегают полностью в угоду производительности.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288641
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt... ко всем классам лепят тень-интерфейсы и регают в контейнере.Ну я же пишу выше, что DI-контейнер не обязывает описывать интерфейсы там, где они не нужны. Он и без них достаточно полезен.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288642
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
winsky!ЕвгенийВпропущено...

DI контейнеры нужно применять в 3 случаях.
1. если используешь внешние сервисы
2. если делаешь поддержку плагинов
3. если пишешь книгу или статью в блог и хочешь показаться офигенно крутым чуваком
аминь+1
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288651
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
winsky!может быть. но говорить, что DI нужно избегать где только можно, я бы не стал. как и ООП кстати :D

В ООП аналогично, понадобились многие года, чтобы понять, что надо при любой возможности избегать наследования. А как было раньше, на заре ООП? Наследование! Только наследование! Возможно некоторым тоже надо за много лет собрать как можно ударов граблями по своему твёрдому лбу, чтобы уяснить для себя, что DI не панацея и не решает всех проблем архитектуры и что во многих случаях без него лучше обойтись.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288653
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КhVostt... ко всем классам лепят тень-интерфейсы и регают в контейнере.Ну я же пишу выше, что DI-контейнер не обязывает описывать интерфейсы там, где они не нужны. Он и без них достаточно полезен.

Вот именно! Если с интерфейсами как-то понятен смысл DI, то без них это уже DI ради DI, начинает казаться, что создание инстансов всех классов стоит переложить на плечи контейнера. Ну как же, он же все зависимости подоткнёт.

Что в итоге? После нескольких месяцев разработки с таким подходом:

1) прочитать и понять программу становится крайне затруднительным делом
2) контролировать поток выполнения программы становится всё сложнее и сложнее
3) производительность, найдя узкое место, решить проблему узкого горлышка в сетях паутины DI может оказаться трудоёмкой задачей

Речь идёт не об полном отказе от DI, а про грамотное использование инструмента, есть другие более эффективные решения, о которых одни забывают, а другие просто тупо не знают, прикрываясь одним единственным заученным паттерном.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288657
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttЕсли с интерфейсами как-то понятен смысл DI, то без них это уже DI ради DIDI ради:

1. Области времени жизни.
2. Централизованное конфигурирование создания объектов.
3. Компактность кода.

Ниже пример из жизни, чего можно избежать при использовании ди-контейнера:
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
        static Installation CreateInstallation(Log log)
        {
            var installation = new Installation();
            var appDbConnectionFactory = new AppDbConnectionFactory();
            var appDbRepository = new AppDbRepository();
            var configuration = new Configuration();
            var uiConfiguration = new UIConfiguration();
            var consoleHelper = new ConsoleHelper();
            var environmentParameters = new EnvironmentParameters();

            installation.Log = log;
            installation.AppDbConnectionFactory = appDbConnectionFactory;
            installation.AppDbRepository = appDbRepository;
            installation.Configuration = configuration;
            installation.UIConfiguration = uiConfiguration;
            installation.ConsoleHelper = consoleHelper;

            appDbRepository.Configuration = configuration;

            uiConfiguration.ConsoleHelper = consoleHelper;
            uiConfiguration.EnvironmentParameters = environmentParameters;

            return installation;
        }
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288658
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttЧто в итоге? После нескольких месяцев разработки с таким подходом:

1) прочитать и понять программу становится крайне затруднительным делом
2) контролировать поток выполнения программы становится всё сложнее и сложнее
3) производительность, найдя узкое место, решить проблему узкого горлышка в сетях паутины DI может оказаться трудоёмкой задачейОт наличия или отсутствия ди-контейнера плохой код лучше не станет.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288659
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
зы: Аспекты ещё бывают на уровне ди-контейнера, но я ими не пользуюсь, посему не упомянул.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288662
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttАлексей Кпропущено...
DI может существовать и быть полезным без IoC, не так ли?

http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html авторЧерез свойства должны устанавливаться лишь необязательные зависимости (обычно, инфраструктурные), для которых существует значение по умолчанию (свойство Logger содержит разумное значение по умолчанию, но может быть заменено позднее). Автор забыл сказать о том, что через свойства устанавливаются циклические зависимости, в том числе и обязательные.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288667
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КНиже пример из жизни, чего можно избежать при использовании ди-контейнера:

В твоём коде всё понятно, что откуда берётся, когда создаётся, ты привёл самый обычный фабричный метод.

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


Алексей К1. Области времени жизни.
2. Централизованное конфигурирование создания объектов.
3. Компактность кода.

1. Есть и обратная сторона, когда у тебя контекст времени жизни ясен и очевиден это одно. Другое, когда время жизни зависит от объекта, который использует зависимость. Один берёт попользоваться, другой хочет забрать себе и отдать тогда, когда сам решит. Лишь в теории и на студенческих примерах всё круто. И да, очень часто злоупотребление DI приводит к утечкам памяти или к нерациональной утилизации ресурсов.

2. Бутстраперы это хорошо, но знаешь в чём подвох? Когда-нибудь программисту надоедать регистрировать всё вручную. Это обязательно наступит рано или поздно. И тогда он захочет автоматическую регистрацию всех компонентов с помощью атрибутов. И вот тогда свой пункт 2 можешь смело вычеркнуть, как не имеющий отношения к реальности.

3. Создание дополнительного уровня косвенности никогда не приводит к компактности кода. Наоборот. Просто ты переносишь создание из одного места в другое. Проблему создания объектов решает не только DI, есть другие способы. К слову.

Если тебя я правильно понял. То ты пропагандируешь идёю: в топку остальные решения, только DI?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288668
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КОт наличия или отсутствия ди-контейнера плохой код лучше не станет.

Говоря о плохом коде, надо говорить о всех аспектов того, почему он плохой. Злоупотребление DI -- один из многих аспектов.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288672
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttАлексей КНиже пример из жизни, чего можно избежать при использовании ди-контейнера:

В твоём коде всё понятно, что откуда берётся, когда создаётся, ты привёл самый обычный фабричный метод.Которого могло не быть, если бы использовался диконтейнер.
hVosttЕсть говорить о контексте применения, то как раз инсталлятор должен конфигурироваться централизовано. Не самый удачный пример в подтверждение твоих мыслей.Данный проект не столь масштабен, чтобы использовать диконтейнер, поэтому он не использован. Но пример показателен.

hVosttАлексей К1. Области времени жизни.
2. Централизованное конфигурирование создания объектов.
3. Компактность кода.

1. Есть и обратная сторона, когда у тебя контекст времени жизни ясен и очевиден это одно. Другое, когда время жизни зависит от объекта, который использует зависимость. Один берёт попользоваться, другой хочет забрать себе и отдать тогда, когда сам решит. Лишь в теории и на студенческих примерах всё круто. И да, очень часто злоупотребление DI приводит к утечкам памяти или к нерациональной утилизации ресурсов.Нет. Области оберегают от утечек ресурсов. В том числе для этого они и придуманы.

hVostt2. Бутстраперы это хорошо, но знаешь в чём подвох? Когда-нибудь программисту надоедать регистрировать всё вручную. Это обязательно наступит рано или поздно. И тогда он захочет автоматическую регистрацию всех компонентов с помощью атрибутов. И вот тогда свой пункт 2 можешь смело вычеркнуть, как не имеющий отношения к реальности.Кроме атрибутов ещё бывают соглашения, которые отлично работают в прикладном коде.

hVostt3. Создание дополнительного уровня косвенности никогда не приводит к компактности кода. Наоборот. Просто ты переносишь создание из одного места в другое. Проблему создания объектов решает не только DI, есть другие способы. К слову.Какие ещё "косвенности"? Тупо экономим на фабричных методах и присваиваниях свойств или вызовах конструкторов. Пример приведён выше.

hVosttЕсли тебя я правильно понял. То ты пропагандируешь идёю: в топку остальные решения, только DI? Я никогда ничего не пропагандирую. Просто ты в очередной раз удивляешь своим идеализмом.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288732
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей К,

Очень не хотелось этого говорить, но.. у тебя DI головного мозга детектед.

Ты даже пример привёл такой, где DI нафиг не втоптался. Ну вот вообще, от его применения может быть только хуже. Живёшь в мире розового сопливого волшебства: области оберегают от утечек — это надо в книгу коллекция заблуждений джуниоров. Регистрация по соглашениям. Экономия на присваивании свойств.

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

Такое ощущение, что ты не код пишешь, а батрачишь задарма :) Голову включай и вылазь из судорга. Серебряной пули не существует. Всё хорошо в меру.


Алексей КПросто ты в очередной раз удивляешь своим идеализмом.

Вот как раз я против идеализма, если ты не заметил. Я не говорю, что DI — зло. Я говорю, что повальное фанатичное увлечение этим у программистов (да это касается чего угодно другого)  — зло.

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

Но ты оставайся при своём мнении, у меня нет цели тебя в чём-то убедить. Возможно сам всё поймёшь когда-нибудь. А возможно и нет.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288745
winsky!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

вы бы не были голословным, и не переходили бы на личности. сделайте проще - приведите пример плохого дизайна с использованием DI и хорошего без него. ну говнокод с DI (пример) и без него (идеальный код).
ждем-с.
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288765
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttВот как раз я против идеализма, если ты не заметил.Я вот что заметил:hVosttЖелательно обходиться без DI там где это можно — максимально. Если что-то делается только внутри одного модуля и не выходит наружу, то в таких случаях лучше вообще избегать использования контейнера.Knockout плохой, Bootstrap ещё хуже, DI можно использовать только для модульности. Я ничего не забыл?
...
Рейтинг: 0 / 0
Dependency injection. Как скрыть внутренние реализации ?
    #39288770
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttАтрибуты это ещё куда ни шло, но соглашения это ещё более слабое правило.Соглашения в EF code-first тобой любимы, а здесь нет. Что за двойные стандарты?
Код: c#
1.
2.
3.
4.
5.
6.
builder
    .RegisterTypes(/*тут все типы из сборки, имена которых оканчиваются на Service*/)
    .AsSelf()
    .AsImplementedInterfaces()
    .PropertiesAutowired(PropertyWiringOptions.AllowCircularDependencies)
    .InstancePerLifetimeScope();


hVosttПойди найди потом правильную имплементацию зависимости. Скажи, а зачем вообще тогда зависимости? Почему бы не получать имплементацию с помощью поиска класса по имени и активацию его через рефлешкен? По сути, разницы нет.Давай напишем свою реализацию ID-контейнера? Готовые решения нас не устраивают?
...
Рейтинг: 0 / 0
58 сообщений из 58, показаны все 3 страниц
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Dependency injection. Как скрыть внутренние реализации ?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]