| Dependency Injection in Controller Classes [message #1171515] |
Tue, 05 November 2013 04:31  |
Eclipse User |
|
|
|
Hi,
I was happy to find out that e(fx)clipse's OSGiFXMLLoader could handle constructor injection (using @Inject) in controller classes. This allows me to define a non-default constructor with all the dependencies my controller needs, which is particularly useful for tests.
This approach, however, has the drawback of mixing field injection with constructor injection, as I always have field injection by the @FXML annotations. This is bad practice, of course, but one might make a case for this because we are dealing with two different and independent types of DI: the field injection is an internal feature of JavaFX, whereas the "real" dependencies are injected using the @Inject annotation.
Where this approach eventually fails is in unit tests with Mockito. Mockito uses either constructor injection or field injection. This means Mockito injects my mocks using the constructor, but does not inject the @FXML-annotated fields.
Is there a recommended way to deal with DI in controllers? Any best practices?
Thanks,
Uwe
|
|
|
| Re: Dependency Injection in Controller Classes [message #1173112 is a reply to message #1171515] |
Wed, 06 November 2013 04:47  |
| Eclipse User |
|
|
|
On 05.11.13 10:32, Uwe San wrote:
> Hi,
>
> I was happy to find out that e(fx)clipse's OSGiFXMLLoader could handle
> constructor injection (using @Inject) in controller classes. This allows
> me to define a non-default constructor with all the dependencies my
> controller needs, which is particularly useful for tests.
>
> This approach, however, has the drawback of mixing field injection with
> constructor injection, as I always have field injection by the @FXML
> annotations. This is bad practice, of course, but one might make a case
I don't see a problem with mixing injection types
(constructor,field,method) in one class. They simply surf different
purposes.
> for this because we are dealing with two different and independent types
> of DI: the field injection is an internal feature of JavaFX, whereas the
> "real" dependencies are injected using the @Inject annotation.
This @FXML is really a strange type of injection and from a JSR330 point
of view it is not injection at all! I see the @FXML stuff more as a
binding than an injection (did you know that freaking @FXML is not
needed at to make the controller fields fill if your field/method is
public!)
>
> Where this approach eventually fails is in unit tests with Mockito.
> Mockito uses either constructor injection or field injection. This means
> Mockito injects my mocks using the constructor, but does not inject the
> @FXML-annotated fields.
Can mockito deal with the @FXML at all?
>
> Is there a recommended way to deal with DI in controllers? Any best
> practices?
>
I'm personally not a friend of constructor injection but like
@PostConstruct much more because then @Inject-Field and method
injections are done already.
Unfortunately in the controller sense @PostConstruct could lead to the
impression that @FXML-"Binding" has been done already which is not right
but for this the initialize-method is used.
I'm not sure what to suggest :-(
Tom
|
|
|
|
Powered by
FUDForum. Page generated in 0.03048 seconds
Home