Comments 8
Я для себя вывел такое правило: если объект не имеет состояния, то его нужно инжектить через конструктор. Это позволяет не кэшировать зависимости и избежать проблем с таким кэшированием связанных.
1. Как у вас достигается типобезопасность, если все зависимости в строковых ключах описаны. DI же популярен в Java, C#, PHP и применяется для больших архитектур, а там без типов никак. А для небольших проектов и DI не нужен. Хорошие DI это Ninject C#, InversifyJS, AngularDI, там все на типах как раз.
2. Как во время рефакторинга узнать, что за реализация стоит за тем или иным строковым ключем-зависимостью? В какой папке искать Salad? Как при написании кода а не в run-time, узнать, что существует класс, который пытается резолвить DI?
3. Как в большом проекте вы решаете проблему дублирующихся имен классов? Есть какие-то составные имена, соглашения по именованию, неймспейсы?
4. Задача подгрузки кусков кода в DI не очень понятное решение. Разве подгрузка чанков бандла такая частая задача, что ее надо добавлять в ядро DI, задача которого собирать код, а не загружать из сети? К примеру, можно разделять приложение на несколько микросервисов или явно прописать загрузку в странице через роутинг и фетч, это же обычно достаточно в одном месте приложения сделать.
5. Добавили асинхронность, как обрабатывать ошибки загрузки, делать тот же retry, рисовать loading, пока код подгружается, отменять загрузку, если во время загрузки первой страницы перешли на вторую?
6. Конвенций для создания инстансов придумывать не надо, достаточно начать использовать typescript или flow+babel и генерить метаданные из аргументов в конструкторе, а через new внутри DI создавать инстансы, как делает Inversify или angular.di, разве нет? Зачем портянки невалидируемых конфигураций (в Java/Spring или PHP/Symfony для этого есть мощные плагины для idea), если можно метаданные вытаскивать из типов/интерфейсов?
7. Как вашу реализацию заставить работать с компонентами, тем же реактом? В Inversify есть хотя бы inversify-react.
8. При применении DI к компонентам вылезает проблема контроля времени жизни зависимостей. Например, есть компонент User и его зависимость UserSettings. Что будет если отобразить User, поменять что-то в UserSettings, и закрыть и снова открыть User?
9. Также есть проблема контроля разделяемости инстансов. Что будет, если есть список User, изменения в UserSettings затронут все User или только один? Поэтому в ангуларе придумали hierarchical-dependency-injection.
2. Как во время рефакторинга узнать, что за реализация стоит за тем или иным строковым ключем-зависимостью? В какой папке искать Salad? Как при написании кода а не в run-time, узнать, что существует класс, который пытается резолвить DI?
3. Как в большом проекте вы решаете проблему дублирующихся имен классов? Есть какие-то составные имена, соглашения по именованию, неймспейсы?
4. Задача подгрузки кусков кода в DI не очень понятное решение. Разве подгрузка чанков бандла такая частая задача, что ее надо добавлять в ядро DI, задача которого собирать код, а не загружать из сети? К примеру, можно разделять приложение на несколько микросервисов или явно прописать загрузку в странице через роутинг и фетч, это же обычно достаточно в одном месте приложения сделать.
5. Добавили асинхронность, как обрабатывать ошибки загрузки, делать тот же retry, рисовать loading, пока код подгружается, отменять загрузку, если во время загрузки первой страницы перешли на вторую?
6. Конвенций для создания инстансов придумывать не надо, достаточно начать использовать typescript или flow+babel и генерить метаданные из аргументов в конструкторе, а через new внутри DI создавать инстансы, как делает Inversify или angular.di, разве нет? Зачем портянки невалидируемых конфигураций (в Java/Spring или PHP/Symfony для этого есть мощные плагины для idea), если можно метаданные вытаскивать из типов/интерфейсов?
7. Как вашу реализацию заставить работать с компонентами, тем же реактом? В Inversify есть хотя бы inversify-react.
8. При применении DI к компонентам вылезает проблема контроля времени жизни зависимостей. Например, есть компонент User и его зависимость UserSettings. Что будет если отобразить User, поменять что-то в UserSettings, и закрыть и снова открыть User?
9. Также есть проблема контроля разделяемости инстансов. Что будет, если есть список User, изменения в UserSettings затронут все User или только один? Поэтому в ангуларе придумали hierarchical-dependency-injection.
Leono,>redyuf задал хорошие вопросы, если шанс получить комментарии от автора доклада или это мёртвый пост?
UFO just landed and posted this here
Ну почему же let, если вы не меняете переменную?:))
www.npmjs.com/package/typescript-ioc
Работает через декораторы. Не умеет интерфейсы, для этого надо уже tsc допиливать, но классы пробрасывает ровно.
Работает через декораторы. Не умеет интерфейсы, для этого надо уже tsc допиливать, но классы пробрасывает ровно.
Инверсия контроля это IoC, а не DI (Внедрение зависимости). Ту ссылку, что вы привели, это DIP принцип инверсии зависимости.
Sign up to leave a comment.
Инверсия зависимостей в мире фронтенда. Лекция Яндекса