Есть ли инверсия управляющих структур для javascript?

Question

Есть ли инверсия управляющих структур для javascript?

Ближайший доступный ответ о стековом потоке, который я смог найти, находится здесь: Как правильно соединить вместе 2 объекта javascript? . Это выглядит как хорошее начало, но я подумал, что смогу найти что-то с более длинной историей разработки.

Я сам использовал только Виндзорский замок, и мне действительно не хватает его в стране веб-клиентов.

Answer 1

Я использую один, вот простой код из спецификации (это CoffeeScript):

di.register 'a', -> 'component a'
di.get('a').should be: 'component a'

Есть также обратные вызовы, различные области действия (приложение, экземпляр, пользовательский), возможность явного назначения компонентов.

DI: https://github.com/alexeypetrushin/rad_core/blob/master/assets/lib/dependency_injection.coffee

Spec: https://github.com/alexeypetrushin/rad_core/blob/master/assets/lib_spec/dependency_injection_spec.coffee

Я использую его для сборки приложения Backbone.js, там много объектов (App, Menu, Notice, ...), и это облегчит мою жизнь.

ВНИМАНИЕ: я использую его внутренне с измененными нативными объектами, поэтому могут быть некоторые ошибки :) Пожалуйста, дайте мне знать о них, я, вероятно, исправлю это через день или два (отправляя через страницу с проблемами https://github.com/alexeypetrushin/rad_core/issues ).

P.S. Не нравится термин IoC, он слишком широк, DI - гораздо более точное определение.

Answer 2

В динамически типизированных языках, таких как JavaScript и Ruby, DI не так уж и полезен.

Основное преимущество DI в статически типизированных языках, таких как Java, заключается в тестировании - заменить реальную реализацию некоторого класса на макет. Это потому, что в Java классы являются неизменяемыми, и вы не можете просто так легко заменить их на mocks - вам нужна целая система DI для этого.

Но в JavaScript вы можете легко заменить существующие классы / методы на фиктивные. Так что DI на самом деле не нужен для достижения тестируемости.

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