|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
Привет. Как я понимаю реализация паттерна DI такова (на примере Asp Net Mvc), что есть один контейнер и в нем зарегистрированы все все все сущности. Как тогда реализовать DI в ситуации,когда у нас в DLLке есть интернальные классы, имеющие смысл внутри только этой DLLки ? Если у нас имеется лишь единый контейнер, куда мы вынуждены зарегистрировать сотню наших интернальных классов, то там свалка вообще получится да и мы тогда отдаем свои интернальные классы наружу. Неужели нужно внутри этой библиотеки организовывать свой внутренний DI что ли ? Да еще скрещивать его с внешним DI, ведь класс доступный публично придется регистрировать в обоих контейнерах. Это прям почти какой-то "containers hell" получается :) Есть какое-то решение для данной проблемы, или нету проблемы вообще ? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2016, 14:49 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotekКак тогда реализовать DI в ситуации,когда у нас в DLLке есть интернальные классы, имеющие смысл внутри только этой DLLки ? С помощью концепции модуля. Именно так и делается, даже в рамках одного приложения и нескольких DLL. Каждый модуль (каждая DLL) сама себя регистрирует в контейнере, свои зависимости. И как раз регистрируются интернальные имплементации публичных интерфейсов. Если интерфейс тоже интернальный, то за пределами модуля всё равно эту зависимость не получить. Но! Если у разработчика DI головного мозга, когда каждый чих делается через зависимость, то эту болезнь надо лечить, а не искать «решение». Желательно обходиться без DI там где это можно — максимально. Если что-то делается только внутри одного модуля и не выходит наружу, то в таких случаях лучше вообще избегать использования контейнера. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2016, 17:34 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttНо! Если у разработчика DI головного мозга, когда каждый чих делается через зависимость, то эту болезнь надо лечить, а не искать «решение». Желательно обходиться без DI там где это можно — максимально. Если что-то делается только внутри одного модуля и не выходит наружу, то в таких случаях лучше вообще избегать использования контейнера. +100500 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2016, 17:40 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttНо! Если у разработчика DI головного мозга, когда каждый чих делается через зависимость, то эту болезнь надо лечить, а не искать «решение». А как иначе быть ? Если не DI будет через конструктор (чаще всего) инжектить зависимости то кот ? Хардкодить создание классов по месту использования ? А как же юнит-тестирование ? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2016, 18:09 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotek, Вы конкретный пример приведите того, что за "интернальные", почему их надо инжектить, почему без этого нельзя покрыть юнит-тестами? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2016, 19:10 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
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.
Либа которая может рассчитать медленно но точно, или быстро но не очень точно (абстрактный пример же). Внешнему миру нужен доступ к IService. Сам сервис зависит от реализаций ICalculator, о которых внешнему миру просто не интересно знать (а может даже и не нужно). Очевидно помещать создание этих классов в Service не правильно потому, что - это сильно свяжет его с этими классами. В частности ему придется знать про некие параметры someData1, someData2. - не получится протестить этот класс, передав ему мок-стаб вместо этих ICalculator. Поэтому получается, что фактически да, нужно использовать DI на каждый чих. Везде, даже во внутренних классах библиотек. Просто стало интересно как правильно конфигурировать интернальные классы в DI контейнере, создал темку. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2016, 19:37 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotekskyANA, Ну пожалуйста. Чисто абстрактный пример. Чисто абстрактный класс вместо интерфейса + factory method - и DI в данном случае не нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 03:34 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotekПоэтому получается, что фактически да, нужно использовать DI на каждый чих. Не получается. Приводить такой пример, для которого оправдано применение DI в подтверждение тезиса «на каждый чих», это как доказывать что молотком забивать гвозди — совершенно нормально. Решать конечно тебе. Но скажу сразу, за повальное применение DI где надо и где не надо, особенно в закрытых модулях как часть внутренней реализации -- по головке тебя за это не погладят. Будешь в джуниорах ходить до старческих штанов. Учись кодить правильно, включай голову! ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 08:05 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotekПросто стало интересно как правильно конфигурировать интернальные классы в DI контейнере, создал темку. В модулях вместо DI, можно использовать классическую реализацию паттерна Стратегия. Возможно, тебе как раз таки не калькулятор тут нужен, а сам метод вычисления, при чём это не зависимость, а явное требование передать конкретный алгоритм для вычисления (быстрый, медленный, унылый, весёлый...). Ты явно не на том сосредоточился. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 08:09 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
[quot hVostt]ProBiotek Желательно обходиться без DI там где это можно — максимально. а можно подробнее? просто это такое максималистское заявление. не могли бы вы объяснить почему так категорично? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 11:18 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
winsky!а можно подробнее? просто это такое максималистское заявление. не могли бы вы объяснить почему так категорично? Что конкретно в этом утверждении не нравится? Давайте обсуждать не характер заявлений (то, как вам кажется), а предметно. Я могу пояснить, что за всё нужно платить. Если DI позволяет решить малой кровью некоторые проблемы в архитектуре, то злоупотребление им может нанести больше ущерба, чем пользы. Это относится к любым инструментам и методикам. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 11:23 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttwinsky!а можно подробнее? просто это такое максималистское заявление. не могли бы вы объяснить почему так категорично? Что конкретно в этом утверждении не нравится? Давайте обсуждать не характер заявлений (то, как вам кажется), а предметно. Я могу пояснить, что за всё нужно платить. Если DI позволяет решить малой кровью некоторые проблемы в архитектуре, то злоупотребление им может нанести больше ущерба, чем пользы. Это относится к любым инструментам и методикам. я не говорил, что не нравится. я сказал, что утверждение слишком громкое. я имею в виду, что я могу вообще обойтись без DI и это будет именно "максимально". и я спрашиваю очень предметно, какой вред может принести использование паттерна? т.е. - в каких случаях его применение оправданно, а в каких нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 11:27 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
winsky!я сказал, что утверждение слишком громкое. ну так и ваш комментарий можно оценить, как слишком злобное, показывающее, что вам категарически что-то не нравится, что почему-то в следующем комментарии вы также категорически отрицаете :) т.е. такой дискурс ни к чему хорошему не приведёт, суждения о суждениях. давайте лучше предметно. winsky!какой вред может принести использование паттерна? употребление DI приводит к новому уровню абстракции, и это усложняет понимание системы. если программист начинает злоупотреблять DI, то прочитать его код становится сложной задачей, а понять — ещё сложнее. стоит ли говорить, к чему это в итоге приводит? об этом хорошо написано у первоисточника, автора этого принципа Роберта Мартина. чтобы не попасть в ловушку абстракций и не создавать лишней косвенности, переусложнённого дизайна, надо изначально понимать, для чего вообще нужен DI. вы вот, сможете ответить на этот вопрос? winsky!т.е. - в каких случаях его применение оправданно, а в каких нет? если сможете ответить на мой вопрос, то он в принципе должен содержать ответ на этот. а если нет, то лучше вам обратиться к специальной литературе и попрактиковаться в реальных приложениях. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 11:46 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
эм... давайте определимся. мы говорим о dependency inversion principle или о паттерне dependency injection? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 12:38 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVostt, Вы тоже в своих ответах весьма абстрактны. не привели ни одного примера (а я привел) когда DI не нужен и КАК его заменить, чтобы классы остались достаточно unit-тестируемы (т.е. без тестирования всей кучей с их зависимостями). Как создавать описанные Вами стратегии и как их передавать в класс, который в них нуждается (кто или что этим будет заниматся, если не DI). Это может быть интересно. Может потом действительно можно будет взять на вооружение. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 13:24 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotekПоэтому получается, что фактически да, нужно использовать DI на каждый чих. Везде, даже во внутренних классах библиотек. Уточните пожалуйста, где в Вашем примере используется DI "во внутренних классах библиотек". ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 14:50 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
skyANA, Ну при конфигурировании IService нужно будет регистрировать его зависимости ICalculator. Потом DI их либо автоматически отрезолвит, либо мы можем сами через метод Resolve<>. Но это происходит вне указанной в примере системы. Т.е. IService должен уже получать на вход сконструированные классы. Вопрос был "привести пример внутренних классов, которые нужно конфигурировать в DI и почему их нельзя тестить без этого". Отвечаю (выше это уже написал), если конструировать ICalculator внутри IService это вынудит IService знать про некие параметры someData1, someData2. А также не позволит его нормально протестировать передав моки-стабы вместо ICalculator. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 15:18 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotek, короче hVost Вам выше уже ответил: каждая DLL сама себя регистрирует в контейнере. А пример Ваш толком ничего не показывает, уж извините :) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 17:43 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
winsky!эм... давайте определимся. мы говорим о dependency inversion principle или о паттерне dependency injection? Мы говорим об DI, который в свою очередь является формой IoC в реализации. Смысл говорить о принципах не применительно к коду? Так вернёся к вопросу. Для чего нужен DI? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 18:29 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotekhVostt, Вы тоже в своих ответах весьма абстрактны. не привели ни одного примера (а я привел) когда DI не нужен и КАК его заменить, чтобы классы остались достаточно unit-тестируемы (т.е. без тестирования всей кучей с их зависимостями). Как создавать описанные Вами стратегии и как их передавать в класс, который в них нуждается (кто или что этим будет заниматся, если не DI). Это может быть интересно. Может потом действительно можно будет взять на вооружение. Я очень конкретно ответил. Примеры кода я приведу, когда вы опишете конкретную проблему. Если вы переживаете, что в контейнере слишком много зависимостей — и что лучше будет, если у каждого модуля будет свой личный контейнер — не стоит этого делать и не стоит переживать. Проблемы не существует. Паттерн Стратегия описан очень хорошо на всех языках, гуглится на раз. Зачем я буду пыжиться и демонстрировать вам свои авторские способности по описанию паттернов, если это уже давно сделано и легко доступно? Паттерн Статегия зачастую гораздо лучше решает некоторые задачи, чем DI. Скажу по секрету, есть ещё и другие архитектурные паттерны. Стоит их изучить. И у вас будет много других гораздо более интересных вопросов, чем беспокойство о количестве зависимостей в контейнере. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 18:49 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVostt, Паттерны я знаю, и кто такие GOF ) Вопрос был в том, как инжектить эти интернальные стратегии - суть зависимости в класс. Ну в принципе я понял Вашу идею о том, чтобы регистрировать все в одном большом контейнере. Просто подумал о том что раз есть классы internal то как это должно правильно соотносить с DI. Ладно может проблемы нету, ок. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2016, 19:01 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotekhVostt, Паттерны я знаю, и кто такие GOF ) Разве? https://ru.wikipedia.org/wiki/Банда_четырёх «Ба́нда четырёх» (кит. трад. 四人幫, упр. 四人帮, пиньинь: Sìrén bāng, палл.: Сы жэнь бан) — термин (фактически идеологический ярлык), используемый в официальной китайской пропаганде и историографии для обозначения группы высших руководителей Коммунистической партии Китая, выдвинувшихся в ходе Культурной революции 1966—1976 годов, являвшихся наиболее приближенными к Мао Цзэдуну лицами в последние годы его жизни. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 10:28 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ЕвгенийВ, Ну я именно это и имел ввиду. А Вы других GOF что ли знаете еще ? ) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 11:39 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ProBiotekЕсли у нас имеется лишь единый контейнер, куда мы вынуждены зарегистрировать сотню наших интернальных классов, то там свалка вообще получится да и мы тогда отдаем свои интернальные классы наружу.Ну и в чём проблема? Ты всё равно из других сборок не сможешь запросить штатным способом internal-типы из контейнера, потому что компилятор выдаст ошибку. Чудеса рефлекшена не рассматриваем. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 12:27 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
Алексей КЧудеса рефлекшена не рассматриваем. как это DI и без чудес рефлекшна ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 12:41 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttwinsky!эм... давайте определимся. мы говорим о dependency inversion principle или о паттерне dependency injection? Мы говорим об DI, который в свою очередь является формой IoC в реализации. Смысл говорить о принципах не применительно к коду? Так вернёся к вопросу. Для чего нужен DI? еще раз, на доступном языке, че за DI? :D ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 14:45 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
winsky!еще раз, на доступном языке, че за DI? :D Т.е. ответа не будет? Хех, ну и ладенько. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 14:48 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttwinsky!эм... давайте определимся. мы говорим о dependency inversion principle или о паттерне dependency injection? Мы говорим об DI, который в свою очередь является формой IoC в реализации. Смысл говорить о принципах не применительно к коду? Так вернёся к вопросу. Для чего нужен DI? ну и, используя ваше же тактику: я не знаю, для чего нужен DI (чтобы тут не имелось в виду). объясните мне пожалуйста. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 14:49 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttwinsky!еще раз, на доступном языке, че за DI? :D Т.е. ответа не будет? Хех, ну и ладенько. нет, конечно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 14:49 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
winsky!я не знаю, для чего нужен DI (чтобы тут не имелось в виду). объясните мне пожалуйста. Конкретизируйте свои вопросы. Это я хотел услышать от вас, что такое DI и для чего он нужен. Вы ответа не знаете, но зачем-то ввязались в спор. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 14:51 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttwinsky!я не знаю, для чего нужен DI (чтобы тут не имелось в виду). объясните мне пожалуйста. Конкретизируйте свои вопросы. Это я хотел услышать от вас, что такое DI и для чего он нужен. Вы ответа не знаете, но зачем-то ввязались в спор. а я и не утверждал, что знаю. я просто молодой джун, вот пытался использовать dependency injection, наткнулся на ваш посо, где вы утверждаете, что нужно максимально избегать использования dependency injection, максимально для меня - это не использовать вовсе. но конкретезировать вы почему-то отказались (ну фразы "этого объяснять не нужно" и т.д.), начав забрасывать меня контрвопросами, достаточно неумными, кстати, мне это даже как джуну видно. уж простите. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 14:56 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
Можно так, все записхать сразу в конечном проекте. Есть свои плюсы - тестирование. Но это не модульность. Хотя слои нарезаны, слабая связность (за исклювением конечного проекта) обеспечена ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 19:16 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
А можно так. Модульность тут рулит просто безгранично. И прикурить на этом не хило (или перейти на Java Spring) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 19:18 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
хвост, кажется об этом говорил, вначале топика ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 19:26 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttЕсли что-то делается только внутри одного модуля и не выходит наружу, то в таких случаях лучше вообще избегать использования контейнера. можешь опытом поделиться, плиз. я пока плохо себе это представляю. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2016, 19:34 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttМы говорим об DI, который в свою очередь является формой IoC в реализации.DI может существовать и быть полезным без IoC, не так ли? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2016, 04:03 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
Алексей КhVosttМы говорим об DI, который в свою очередь является формой IoC в реализации.DI может существовать и быть полезным без IoC, не так ли? http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2016, 15:01 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
Алексей К, Сейчас с DI происходит примерно тоже самое, что с ООП много лет назад. Доходит до истерии, на собеседованиях главенствующее положение занимают вопросы по DI. Многие разработчики тотально и категорически впадают в крайности по принципу «масло кашей не испортишь», ко всем классам лепят тень-интерфейсы и регают в контейнере. Идёт война контейнеров. В общем, ещё пару годков и уляжется. Трупы склюют вороны. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2016, 15:07 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttАлексей Кпропущено... DI может существовать и быть полезным без IoC, не так ли? http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html мне показалось, может, но Алексей задал риторический вопрос.. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2016, 18:22 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttАлексей К, Сейчас с DI происходит примерно тоже самое, что с ООП много лет назад. Доходит до истерии, на собеседованиях главенствующее положение занимают вопросы по DI. Многие разработчики тотально и категорически впадают в крайности по принципу «масло кашей не испортишь», ко всем классам лепят тень-интерфейсы и регают в контейнере. Идёт война контейнеров. В общем, ещё пару годков и уляжется. Трупы склюют вороны. может быть. но говорить, что DI нужно избегать где только можно, я бы не стал. как и ООП кстати :D ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2016, 18:30 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
winsky!hVosttАлексей К, Сейчас с DI происходит примерно тоже самое, что с ООП много лет назад. Доходит до истерии, на собеседованиях главенствующее положение занимают вопросы по DI. Многие разработчики тотально и категорически впадают в крайности по принципу «масло кашей не испортишь», ко всем классам лепят тень-интерфейсы и регают в контейнере. Идёт война контейнеров. В общем, ещё пару годков и уляжется. Трупы склюют вороны. может быть. но говорить, что DI нужно избегать где только можно, я бы не стал. как и ООП кстати :D DI контейнеры нужно применять в 3 случаях. 1. если используешь внешние сервисы 2. если делаешь поддержку плагинов 3. если пишешь книгу или статью в блог и хочешь показаться офигенно крутым чуваком ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2016, 18:37 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
ЕвгенийВwinsky!пропущено... может быть. но говорить, что DI нужно избегать где только можно, я бы не стал. как и ООП кстати :D DI контейнеры нужно применять в 3 случаях. 1. если используешь внешние сервисы 2. если делаешь поддержку плагинов 3. если пишешь книгу или статью в блог и хочешь показаться офигенно крутым чуваком аминь ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2016, 18:44 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
winsky!hVosttАлексей К, Сейчас с DI происходит примерно тоже самое, что с ООП много лет назад. Доходит до истерии, на собеседованиях главенствующее положение занимают вопросы по DI. Многие разработчики тотально и категорически впадают в крайности по принципу «масло кашей не испортишь», ко всем классам лепят тень-интерфейсы и регают в контейнере. Идёт война контейнеров. В общем, ещё пару годков и уляжется. Трупы склюют вороны. может быть. но говорить, что DI нужно избегать где только можно, я бы не стал А вот в Stack Overflow избегают полностью в угоду производительности. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2016, 20:42 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVostt... ко всем классам лепят тень-интерфейсы и регают в контейнере.Ну я же пишу выше, что DI-контейнер не обязывает описывать интерфейсы там, где они не нужны. Он и без них достаточно полезен. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 03:56 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
winsky!ЕвгенийВпропущено... DI контейнеры нужно применять в 3 случаях. 1. если используешь внешние сервисы 2. если делаешь поддержку плагинов 3. если пишешь книгу или статью в блог и хочешь показаться офигенно крутым чуваком аминь+1 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 04:00 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
winsky!может быть. но говорить, что DI нужно избегать где только можно, я бы не стал. как и ООП кстати :D В ООП аналогично, понадобились многие года, чтобы понять, что надо при любой возможности избегать наследования. А как было раньше, на заре ООП? Наследование! Только наследование! Возможно некоторым тоже надо за много лет собрать как можно ударов граблями по своему твёрдому лбу, чтобы уяснить для себя, что DI не панацея и не решает всех проблем архитектуры и что во многих случаях без него лучше обойтись. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 05:39 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
Алексей КhVostt... ко всем классам лепят тень-интерфейсы и регают в контейнере.Ну я же пишу выше, что DI-контейнер не обязывает описывать интерфейсы там, где они не нужны. Он и без них достаточно полезен. Вот именно! Если с интерфейсами как-то понятен смысл DI, то без них это уже DI ради DI, начинает казаться, что создание инстансов всех классов стоит переложить на плечи контейнера. Ну как же, он же все зависимости подоткнёт. Что в итоге? После нескольких месяцев разработки с таким подходом: 1) прочитать и понять программу становится крайне затруднительным делом 2) контролировать поток выполнения программы становится всё сложнее и сложнее 3) производительность, найдя узкое место, решить проблему узкого горлышка в сетях паутины DI может оказаться трудоёмкой задачей Речь идёт не об полном отказе от DI, а про грамотное использование инструмента, есть другие более эффективные решения, о которых одни забывают, а другие просто тупо не знают, прикрываясь одним единственным заученным паттерном. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 05:47 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 06:26 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttЧто в итоге? После нескольких месяцев разработки с таким подходом: 1) прочитать и понять программу становится крайне затруднительным делом 2) контролировать поток выполнения программы становится всё сложнее и сложнее 3) производительность, найдя узкое место, решить проблему узкого горлышка в сетях паутины DI может оказаться трудоёмкой задачейОт наличия или отсутствия ди-контейнера плохой код лучше не станет. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 06:27 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
зы: Аспекты ещё бывают на уровне ди-контейнера, но я ими не пользуюсь, посему не упомянул. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 06:32 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttАлексей Кпропущено... DI может существовать и быть полезным без IoC, не так ли? http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html авторЧерез свойства должны устанавливаться лишь необязательные зависимости (обычно, инфраструктурные), для которых существует значение по умолчанию (свойство Logger содержит разумное значение по умолчанию, но может быть заменено позднее). Автор забыл сказать о том, что через свойства устанавливаются циклические зависимости, в том числе и обязательные. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 07:01 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
Алексей КНиже пример из жизни, чего можно избежать при использовании ди-контейнера: В твоём коде всё понятно, что откуда берётся, когда создаётся, ты привёл самый обычный фабричный метод. Есть говорить о контексте применения, то как раз инсталлятор должен конфигурироваться централизовано. Не самый удачный пример в подтверждение твоих мыслей. Алексей К1. Области времени жизни. 2. Централизованное конфигурирование создания объектов. 3. Компактность кода. 1. Есть и обратная сторона, когда у тебя контекст времени жизни ясен и очевиден это одно. Другое, когда время жизни зависит от объекта, который использует зависимость. Один берёт попользоваться, другой хочет забрать себе и отдать тогда, когда сам решит. Лишь в теории и на студенческих примерах всё круто. И да, очень часто злоупотребление DI приводит к утечкам памяти или к нерациональной утилизации ресурсов. 2. Бутстраперы это хорошо, но знаешь в чём подвох? Когда-нибудь программисту надоедать регистрировать всё вручную. Это обязательно наступит рано или поздно. И тогда он захочет автоматическую регистрацию всех компонентов с помощью атрибутов. И вот тогда свой пункт 2 можешь смело вычеркнуть, как не имеющий отношения к реальности. 3. Создание дополнительного уровня косвенности никогда не приводит к компактности кода. Наоборот. Просто ты переносишь создание из одного места в другое. Проблему создания объектов решает не только DI, есть другие способы. К слову. Если тебя я правильно понял. То ты пропагандируешь идёю: в топку остальные решения, только DI? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 07:22 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
Алексей КОт наличия или отсутствия ди-контейнера плохой код лучше не станет. Говоря о плохом коде, надо говорить о всех аспектов того, почему он плохой. Злоупотребление DI -- один из многих аспектов. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 07:23 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttАлексей КНиже пример из жизни, чего можно избежать при использовании ди-контейнера: В твоём коде всё понятно, что откуда берётся, когда создаётся, ты привёл самый обычный фабричный метод.Которого могло не быть, если бы использовался диконтейнер. hVosttЕсть говорить о контексте применения, то как раз инсталлятор должен конфигурироваться централизовано. Не самый удачный пример в подтверждение твоих мыслей.Данный проект не столь масштабен, чтобы использовать диконтейнер, поэтому он не использован. Но пример показателен. hVosttАлексей К1. Области времени жизни. 2. Централизованное конфигурирование создания объектов. 3. Компактность кода. 1. Есть и обратная сторона, когда у тебя контекст времени жизни ясен и очевиден это одно. Другое, когда время жизни зависит от объекта, который использует зависимость. Один берёт попользоваться, другой хочет забрать себе и отдать тогда, когда сам решит. Лишь в теории и на студенческих примерах всё круто. И да, очень часто злоупотребление DI приводит к утечкам памяти или к нерациональной утилизации ресурсов.Нет. Области оберегают от утечек ресурсов. В том числе для этого они и придуманы. hVostt2. Бутстраперы это хорошо, но знаешь в чём подвох? Когда-нибудь программисту надоедать регистрировать всё вручную. Это обязательно наступит рано или поздно. И тогда он захочет автоматическую регистрацию всех компонентов с помощью атрибутов. И вот тогда свой пункт 2 можешь смело вычеркнуть, как не имеющий отношения к реальности.Кроме атрибутов ещё бывают соглашения, которые отлично работают в прикладном коде. hVostt3. Создание дополнительного уровня косвенности никогда не приводит к компактности кода. Наоборот. Просто ты переносишь создание из одного места в другое. Проблему создания объектов решает не только DI, есть другие способы. К слову.Какие ещё "косвенности"? Тупо экономим на фабричных методах и присваиваниях свойств или вызовах конструкторов. Пример приведён выше. hVosttЕсли тебя я правильно понял. То ты пропагандируешь идёю: в топку остальные решения, только DI? Я никогда ничего не пропагандирую. Просто ты в очередной раз удивляешь своим идеализмом. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 07:44 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
Алексей К, Очень не хотелось этого говорить, но.. у тебя DI головного мозга детектед. Ты даже пример привёл такой, где DI нафиг не втоптался. Ну вот вообще, от его применения может быть только хуже. Живёшь в мире розового сопливого волшебства: области оберегают от утечек — это надо в книгу коллекция заблуждений джуниоров. Регистрация по соглашениям. Экономия на присваивании свойств. Атрибуты это ещё куда ни шло, но соглашения это ещё более слабое правило. Пойди найди потом правильную имплементацию зависимости. Скажи, а зачем вообще тогда зависимости? Почему бы не получать имплементацию с помощью поиска класса по имени и активацию его через рефлешкен? По сути, разницы нет. Такое ощущение, что ты не код пишешь, а батрачишь задарма :) Голову включай и вылазь из судорга. Серебряной пули не существует. Всё хорошо в меру. Алексей КПросто ты в очередной раз удивляешь своим идеализмом. Вот как раз я против идеализма, если ты не заметил. Я не говорю, что DI — зло. Я говорю, что повальное фанатичное увлечение этим у программистов (да это касается чего угодно другого) — зло. Я бы так не говорил касательно DI, если бы своими глазами не видел загубленных проектов, где сплошь один DI, почти любой класс инстанцируется исключительно из контейнера, доходит до маразма. Хотя и без маразма уже мрак. Но ты оставайся при своём мнении, у меня нет цели тебя в чём-то убедить. Возможно сам всё поймёшь когда-нибудь. А возможно и нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 10:13 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVostt, вы бы не были голословным, и не переходили бы на личности. сделайте проще - приведите пример плохого дизайна с использованием DI и хорошего без него. ну говнокод с DI (пример) и без него (идеальный код). ждем-с. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 10:31 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttВот как раз я против идеализма, если ты не заметил.Я вот что заметил:hVosttЖелательно обходиться без DI там где это можно — максимально. Если что-то делается только внутри одного модуля и не выходит наружу, то в таких случаях лучше вообще избегать использования контейнера.Knockout плохой, Bootstrap ещё хуже, DI можно использовать только для модульности. Я ничего не забыл? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 10:57 |
|
Dependency injection. Как скрыть внутренние реализации ?
|
|||
---|---|---|---|
#18+
hVosttАтрибуты это ещё куда ни шло, но соглашения это ещё более слабое правило.Соглашения в EF code-first тобой любимы, а здесь нет. Что за двойные стандарты? Код: c# 1. 2. 3. 4. 5. 6.
hVosttПойди найди потом правильную имплементацию зависимости. Скажи, а зачем вообще тогда зависимости? Почему бы не получать имплементацию с помощью поиска класса по имени и активацию его через рефлешкен? По сути, разницы нет.Давай напишем свою реализацию ID-контейнера? Готовые решения нас не устраивают? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 11:08 |
|
|
start [/forum/topic.php?all=1&fid=20&tid=1400408]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
248ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
72ms |
get tp. blocked users: |
1ms |
others: | 256ms |
total: | 618ms |
0 / 0 |