After migrating from PlayFramework version 2.4 to version 2.5, I need to inject dependencies.
I'm avoiding to use #Inject for constructor DI as in this the caller class of the class that has #Inject also needs to get the same dependencies injected to call the callee's constructor. This increases code complexity.
Please suggest any other way of DI which does not involve injecting to constructor.
MacWire looks like a great tool for constructor injection. It is macro-based and thus typesafe and non invasive. The README page has a very good documentation, definitely worth a look IMHO.
Related
in my opinion, the get_it package is one of ways to dependency injection in flutter, is that so? I'm just not sure about it, please help me figure it out
Rather not. get_it describes itself as a Service Locator, as can be seen it its documentation. A service locator is a different pattern than Dependency Injection, although they can be used for the same purpose.
Both approaches aim towards abstracting object interfaces from their actual implementation, but do it in slightly different ways. In classical dependency injection (e.g. via constructor or interface injection), each object holds a reference to the objects that implements its specific behavior. With the service locator pattern, there is just one single object - getIt() in our case - that can be used to find implementations across the whole application.
A great and more extensive discussion of these appraoches can be found in this article by Martin Fowler.
Sorry for this basic question I am asking but can someone tell me if dagger dependency injection can work just with #module, #provides #Inject etc. That is without using #component annotation?
In spring DI, we use #componentScan to let spring know where to find beans. What is the equivalent of this in dagger?
You always need #Component. This is the entry point for dependencies from "outside".
When I say "outside" I mean the case where after the dependency graph inside the Component is created and now it is a time for some Activity to be Injected for example. So the component exposed dependencies for the "outside".
At the same time, a component can share its dependencies with other Subcomponents for example.
The Components depend on the Modules to know how to create dependencies.
As of Play 2.4 the Plugin class is deprecated and one should use the Module class instead.
I've understood file play.plugins is no longer necessary and custom modules should be registered in application.conf as documented here.
But how do I migrate my old plugins? The Module class doesn't contain methods onStart and onStop... Is there an example somewhere?
This pull request has the full Redis plugin migration from 2.3 to 2.4. They use the constructor for the onStart and ApplicationLifecycle for the onStop in SedisPoolProvider.
https://github.com/typesafehub/play-plugins/pull/148/files
Documentation explains that the goal is to provide bindings in a DI framework agnostic way. This is the reason I believe there is no trait with onStart and onStop to implement. The agnostic way is to use constructor and/or by injecting a lifecycle module like ApplicationLifecycle.
Is it possible for Autofac modules to declare registrations that it depends on?
It would be nice of Autofac could validate that these dependencies are fulfilled before a further runtime error.
The idea comes from one of Java's dependency injection framework, Guice which has a requireBinding function within its modules.
Autofac modules do not support the ability to declare their "requirements". Given the flexible nature of Autofac with the ability to provide dynamic registration sources and such, providing a function like requireBinding would require quite a bit of change to the internals of Autofac. (It is for this same reason that Autofac can't analyze potential object resolution failures at runtime without actually resolving the objects in question.)
Just thinking of implementing Guice in scala
Any sample code ?
Unless you specifically need Guice to add Scala to an existing Java-based project that uses framework, I'd advocate that you just use built-in language features instead.
Traits and implicits can give you all the Dependency Injection you'll need. You might also want to search online for the Cake pattern.
This post about DI in Scala will be able to help you to get going with Guice. See Using Google Guice topic.