Здравствуйте, Министр Промышленности, Вы писали:
МП>>>вопрос был в разрезе целесообразности использования DI МП>>>если можно использовать нормальные конструкторы, зачем там применять DI? МП>>>или даже зачем заменять нормальное конструирование дополнительными DI сборками и конфигурированием этого всего
M>>Как вообще можно писать бизнес приложения без DI ума не приложу
МП>подозрительное заявление
Не знаю на чем вы пишите, но на C# DI уже давно входит в базовый фреймворк и без него давно никто не работает
Не обязательно весь проект, просто пример как вы пишите классы решающие бизнес задачи, как передаете в них зависимости?
В каком месте приложения конструируете зависимости?
Зачем делаете это руками если есть контейнер который справится с этим сам и без проблем?
M>Нормальное DI как раз и работает через конструкторы. Как вообще можно писать бизнес приложения без DI ума не приложу, покажите пример, а мы посмотрим.
Для банковского или шире, финансового ПО, где требования меняются часто, может и критично. Для любых других приложений может и не надо.
МП>кто-то может популярно расписать преимущества либо природу явления популярности? МП>(часть плюсов знаю и гипотезы-то я имею, но мнение всё равно такое)
инструмент должен решать задачу.
DI не везде нужен, особенно в вин-формах, имхо.
но вот тебе пример из недавнего с нашего проекта.
есть сервис, пусть будет MyService, который делает достаточно долгий запрос за статическими данными.
есть интерфейс, понятное дело, IMyService.
этот сервис используется в большом количестве мест проекта. через интеферйс, понятное дело, не напрямую создавая инстанс.
запустив нагрузочное тестирование, мы поняли, что мы упираемся в производительность этого сервиса, и если бы мы закешировали данные, получили бы приличный прирост производительности.
дальше, мы создали над MyService обычный декоратор, аля MyServiceWithCache, который так же реализует IMyService интерфейс. всё что там нужно было, поменять регистрацию в DI в одном месте.
дальше, везде подхватилась новая реализаций, реализация нашего декоратора. приложение взлетело.
это лишь один и маленький пример. я могу привести много больше
МП>если можно использовать нормальные конструкторы, зачем там применять DI? МП>или даже зачем заменять нормальное конструирование дополнительными DI сборками и конфигурированием этого всего
тебе известны такие понятия как SOLID, и, конкретно, D из этой группы? или что такое DI как паттерн и для чего он вообще нужен?
Здравствуйте, Министр Промышленности, Вы писали:
МП>С моей профессиональной точки зрения DI фреймворки не нужны.
Не нужны для бизнес-логики.
МП>Они затрудняют распутывание кода, МП>понижают гибкость автоматического рефакторинга (в частности ReSharper-ом) МП>и это не перекрывается гибкостью подстановки mock-объектов
Распутывание кода и рефакторинг в основном затрудняет тотальное использование интерфейсов, которые так любят использовать в DI фреймворках.
МП>кто-то может популярно расписать преимущества либо природу явления популярности? МП>(часть плюсов знаю и гипотезы-то я имею, но мнение всё равно такое)
Тут такое дело. Сам по себе DI требует некоторого осмысления. В доисторические времена мы пёрлись от понимания таких вещей как косвенная адресация в ассемблере. Сегодня эту нишу занял DI. А осмыслив эту штуку народ переходит на следующий уровень, где DI превращается в золотой молоток — уверенность в полной универсальности данного инструмента.
Ещё одним усугубляющим проблему фактором является то, что большинство программистов не понимают разницы между написанием таких вещей как System.String и MyCompamy.CustomerService.GetCustomerByID. Не понимают того, что для этих вещей нефункциональные требования абсолютно разные.
Первое — это универсальный код, предназначенный для многократного повторного использования.
Второе — бизнес логика, которая за время своего жизненного цикла будет многократно меняться.
Проблема и непонимание заключается в том, что бизнес логика, которая будет многократно менятся, пишется как универсальный код, предназначенный для многократного повторного использования. Мы же все здесь минимум архитекторы, так ведь? Любой код сразу пишем как всеоблемющий всемогутор. А раз так, то как же можно получить информацию о кастомере без DI фреймворка и пары IoC контейнеров? Никак не можно.
Ещё один момент. Написание повторно используемых компонентов — это тоже скил, который нужно прокачивать. Без этого получаются не повторно используемые компоненты, а кособокие уродцы.
В результате имеем — неумеха с золотым молотком пишет со всем старанием бизнес логику в стиле универсального всемогутера.
Какждый раз когда я вижу в проекте использование DI фреймворков и IoC контейнеров у меня возникакет именно такое впечатление.
Если нам не помогут, то мы тоже никого не пощадим.
САД>тебе известны такие понятия как SOLID, и, конкретно, D из этой группы? или что такое DI как паттерн и для чего он вообще нужен?
Выше уже обратили внимание, что D. Injection D. Inversion не одно и тоже. В SOLID речь идет об Inversion,
для этого Injection можно не использовать, а просто придерживаться соотв. принципов разработки и проектирования.
Достигается легко -- везде и всюду использовать интерфейсы или базовые классы.
Контейнер же вообще не требует от программиста написания оператора new в явном виде, кроме всяческих
абстрактных фабрик и не более.
S>Выше уже обратили внимание, что D. Injection D. Inversion не одно и тоже. В SOLID речь идет об Inversion, S>для этого Injection можно не использовать, а просто придерживаться соотв. принципов разработки и проектирования.
это один из моих любимых вопросов на интервью. потому как, что такое DI, понимают многие, а вот DIP, увы, единицы.
S>Достигается легко -- везде и всюду использовать интерфейсы или базовые классы.
не всегда так.
S>Контейнер же вообще не требует от программиста написания оператора new в явном виде, кроме всяческих S>абстрактных фабрик и не более.
он и он никак не решает вопросы с DIP. а так же с L.
Здравствуйте, Министр Промышленности, Вы писали:
МП>>>нормальные обычные конструкторы, МП>>>ну либо статические конструкторы,
МП>вопрос был в разрезе целесообразности использования DI
до этого момента, когда ты спрашивал про DI-фреймворки, всё было правильно,
а сейчас съехал в сторону
передача зависимостей в конструкторе это такое же средство реализации DI
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>он и он никак не решает вопросы с DIP.
Он упрощает\помогает в решение этого вопроса.
САД>а так же с L.
Про L не скажу, но думается зависит от конфигурации и прочих продвинутых плюшек.
Т.е. где надо вернуть такой-то тип, где-то такой-то. По идее это как-то настраиваемо
в том же Castle.Windsdor.
Это меня на текущем проекте просто достало. Чуваки с золотыми молотками суют это уродство во все щели — и куда надо, и куда не надо (на самом деле почти никуда не надо). Гора интерфейсов, за которыми найти не возможно просто ничего. Тьфу.
Здравствуйте, AlexRK, Вы писали:
ARK>Это меня на текущем проекте просто достало. Чуваки с золотыми молотками суют это уродство во все щели — и куда надо, и куда не надо (на самом деле почти никуда не надо). Гора интерфейсов, за которыми найти не возможно просто ничего. Тьфу.
Я такое при возможности выкорчёвываю нещадно. На самом деле есть очень простой и эффективный критерий правильно написанной бизнес логики. Если логически законченный функционал бизнес логики легко извлекается из одного проекта и спокойно переносится в другой, то это правильно написанная бизнес логика. Если же для переезда в соседний дом нужно перетащить с собой весь подъезд, то это не код, а кусок оверинжениринга.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vopl, Вы писали:
G>>Уже? Доброе утро. Погугли что означает D в SOLID V>Попробуй сам погуглить, что же именно означает D в SOLID
ололо
inversion это не injection
Здравствуйте, varenikAA, Вы писали:
AA>Если у вас возникают циклические зависимости между компонентами, то вам не избежать DI.
Выстрелив в ногу ее надо потом отрубить, чтобы не мешала...
AK>При чём здесь строковые константы? Я не понимаю. AK>Можете дать какой-нибудь пример?
Я похоже переврал, что конкретно можно делать только resolve по имени, что ослабляло бы типизацию.
Но вот дискуссия на SO, которую я считаю релевантной -- https://stackoverflow.com/a/4988337/241446
В частности вот это:
Errors are pushed to run-time. If you configure your Guice module incorrectly (circular reference, bad binding, ...) most of the errors are not uncovered during compile-time. Instead, the errors are exposed when the program is actually run.
Т.е. из-за DI некоторые ошибки будут заметны на стадии исполнения, нежели при компиляции. Вероятно это ТС имел в виду.
Если нам не помогут, то мы тоже никого не пощадим.
