Каковы отношения между OSGi и Внедрением зависимости
У меня есть многие из них:
# For each pose in the document
doc.elements.each('//pose') do |pose| ...
# For each sprite in sprites
@sprites.each do |sprite| ...
# For each X in Y
for X in Y do ...
я пытаюсь сократить это, все же.: (
3 ответа
Они не связаны.
Изменить:
DI - это концепция , впервые описанная Мартином Фаулером , OSGi - это модульная система для Java, которая реализует полную и динамическую компонентную модель , определенную OSGi Alliance .
- DI может использоваться на языках, отличных от Java, OSGi специфична для Java
- OSGi пытается для решения проблемы версионных компонентов DI является альтернативой старому шаблону Service Locator.
Они концептуально связаны тем, что оба обеспечивают механизмы «разделения проблем».
OSGI делает это на уровне модуля - подумайте об архитектуре Eclipse с несколькими подключаемыми модулями, каждый из которых отвечает за определенные проблема / особенность.
DI ориентирован на объектный уровень - он предоставляет средства для создания приложений из множества связанных вместе объектов, каждый из которых отвечает за свою конкретную функциональность.
Технологически они различны. OSGI - это спецификация, имеющая несколько реализаций. DI раньше был шаблоном проектирования с несколькими реализациями и API. Однако в JCP недавно была проделана работа по стандартизации API-интерфейсов DI ( JSR 330 )
The OSGi specification is composed of two separated parts: core and compendium.
The core part is the specification of a module system for Java. As such, the core specification has no relationship with the concept of DI.
The compendium part, on the other side, specifies a series of services that an OSGi container can provide. Among this services you'll find the "Declarative Services Specification" (OSGi Compendium Services, Chapter 112) that is the first attempt to bring the familiar concept of DI into OSGi. The idea is simple: since OSGi allows the developer to implement, define and register services, the Declarative Services Specification gives the developer the possibility to define a service dependent on a series of other underlying services. That's a particularly interesting (and hard) problem in OSGi, because services are by definition unreliable, and they can appear and disappear.
Beside the Declarative Services Specification, there are at least two other popular solution trying to provide a more powerful DI framework in OSGi:
- Peaberry, an extension of the Guice framework for OSGi
- Spring Dynamic Modules for OSGi (aka Spring DM), the OSGi extension of the Spring Framework
It worth noting that the upcoming R4.2 version of the OSGi specification will contain a new compendium specification named Blueprint Services, that will provide a complete DI solution for OSGi based on the Spring DM framework (the Spring team has heavily contributed to this new specification)