I\'m looking at the scaly code example from play-mailer: https://github.com/playframework/play-mailer
It goes basically like this:
class MyComponent @
Since you closed your issue on the original GitHub repo, I don't know if this answer is still necessary but since you don't fully understand the use of a DI framework and I find it incredibly important to learn this skill, I'll try to explain it here and list some benefits.
First off, the way you are instantiating your instance doesn't give the DI framework a chance to inject your dependencies. Since new
is a language keyword, DI can't interfere and the dependencies you need for your class can't be injected. How it is done is through constructor or field injection. I'll mainly focus on constructor injection because that is "standard" in the scala world.
If you specify a constructor argument with the @Injected
annotation, you are basically telling the DI framework to resolve this dependency from the container. The DI framework goes and looks for an entry of that object inside its container. If it doesn't exists, it will create it (and resolve its dependencies in the process) and if it's annotated with @Singleton
also save this instance for future use. Most DI frameworks require you to specify a starting class in most cases but because you are using Play! Framework this is not necessary. When you want to use a particular module inside your controller you can do this:
import javax.inject.Inject
import play.api.mvc.Controller
class Test @Inject() (val dependency: FooClass) extends Controller {
...
}
In this case FooClass
is the class name of the dependency you want to inject into your controller. Let's say FooClass
has Play's Application
as a dependency this will be injected, because Play provides a couple pre-bonded presets like Application
but also ActorSystem
.
This is possible because Play! Framework uses DependencyInjectedRoutes
. If you were to create an Actor outside of an Controller you would need to specify that inside a module class but that is explained in this link and this link.
There is also a concept of using Traits
inside your controller and then later on wiring together the traits with the implementation classes but I think that is a bit too complicated for now.
If you want some benefits and succes stories to this method of writing applications, here is a good resource: https://softwareengineering.stackexchange.com/a/19204/164366
If you want something to read on this concept:
I hope this clears things up! If you have question, please do ask!