Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Eclipse4/RCP/Dependency Injection"
Line 1: | Line 1: | ||
− | + | One often-heard complaint of using the Eclipse 3.x Platform was that finding and obtaining services required navigating a deep chain of dependencies (e.g., obtaining an ''IStatusLineManager''). Accessing the services required using singletons, which is problematic for app servers like RAP/Riena. Dependency Injection (DI) is one approach to circumvent these problems: rather than require client code to know how to access a service, the client instead describes the service required, and the platform is responsible for configuring the object with an appropriate service. | |
− | + | * DI is not new. Pointers to other projects and books (e.g., Dhanji Prasanna's ''Dependency Injection'') | |
+ | * Different approaches: separate configuration, or annotating POJOs with injection points. | ||
+ | |||
+ | The Eclipse 4 Application Platform provides a [[http://jcp.org/en/jsr/detail?id=330 | JSR 330]]-compatible dependency injection (DI) framework, similar to [[http://springframework.org/ Spring]] or [[http://code.google.com/p/google-guice Guice]]. Instead of PlatformUI.getWorkbench().getHelpSystem(), E4AP plugins can have the HelpSystem injected into an object directly. | ||
+ | |||
+ | |||
+ | == Using the E4AP DI Framework == | ||
+ | |||
+ | * E4AP's injector uses annotations | ||
+ | ** JSR 330 annotations: @Inject, @PostConstruct, @PreDestroy, @Named | ||
+ | ** E4AP-specific annotations: @Preference, @Event, @UIEvent | ||
+ | * List of available services | ||
+ | ** E4AP services | ||
+ | ** OSGi services | ||
+ | * plugins: org.eclipse.e4.core.di, org.eclipse.e4.core.di.extensions, and org.eclipse.e4.ui.di | ||
+ | * Accessing the IEclipseContext | ||
+ | ** Adding, setting, or modifying variables | ||
+ | *** Why is modify different from set | ||
+ | |||
+ | == Advantages / Disadvantages == | ||
DI provides a number of advantages: | DI provides a number of advantages: | ||
Line 12: | Line 31: | ||
* Concerns about discoverability of services - cannot use code completion to find out what is available. | * Concerns about discoverability of services - cannot use code completion to find out what is available. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 14:30, 7 April 2011
One often-heard complaint of using the Eclipse 3.x Platform was that finding and obtaining services required navigating a deep chain of dependencies (e.g., obtaining an IStatusLineManager). Accessing the services required using singletons, which is problematic for app servers like RAP/Riena. Dependency Injection (DI) is one approach to circumvent these problems: rather than require client code to know how to access a service, the client instead describes the service required, and the platform is responsible for configuring the object with an appropriate service.
- DI is not new. Pointers to other projects and books (e.g., Dhanji Prasanna's Dependency Injection)
- Different approaches: separate configuration, or annotating POJOs with injection points.
The Eclipse 4 Application Platform provides a [| JSR 330]-compatible dependency injection (DI) framework, similar to [Spring] or [Guice]. Instead of PlatformUI.getWorkbench().getHelpSystem(), E4AP plugins can have the HelpSystem injected into an object directly.
Using the E4AP DI Framework
- E4AP's injector uses annotations
- JSR 330 annotations: @Inject, @PostConstruct, @PreDestroy, @Named
- E4AP-specific annotations: @Preference, @Event, @UIEvent
- List of available services
- E4AP services
- OSGi services
- plugins: org.eclipse.e4.core.di, org.eclipse.e4.core.di.extensions, and org.eclipse.e4.ui.di
- Accessing the IEclipseContext
- Adding, setting, or modifying variables
- Why is modify different from set
- Adding, setting, or modifying variables
Advantages / Disadvantages
DI provides a number of advantages:
- Clients are able to write POJOs and list the services they need. The DI framework provides
- Useful for testing: the assumptions are placed in the DI container rather than in the client code
DI has some disadvantages too:
- Concerns about discoverability of services - cannot use code completion to find out what is available.