Scala依赖注入用于单独配置的编译时间

Question

Now firstly I realise the title is extremely broad, so let me describe the use case.

Background:

I'm currently teaching myself Scala+Gradle (because I like the flexibility and power of gradle and the much more legible build files)

As such with learning new languages its often best to make applications that you can actually use, and being primarily a PHP (with Symfony) programmer and formerly a Java programmer, there are many patterns that could carry across from both paradigms.

Use Case:

I'm writing an application where I am experimenting with a Provider+Interface(trait) layout, the goal is to define traits that encompass all the expected functionality for any particular type of component eg a ConfigReaderTrait and a YamlConfigReager as a provider. Theoretically the advantage of this would be to allow me to switch out core mechanisms or even architectural components with minimal effort, this allows for a great deal of R&D and experimenting.

PHP Symfony Influence

Now currently I work as a pure PHP dev, and as such has been introduced to Symfony, which has a brilliant Dependency Injection framework where the dependencies are defined in yaml files, and can be delegated to sub directories. I like this, because unlike with SBT I am unphased by using different languages for different purposes (eg groovy with gradle for build scripts) and I want to maintain a separation of concerns.

Such that each type of interface/trait or bundle of related functionality should be able to have its own DI config, and I would prefer it separate from the scala code itself.

Now for Scala....

Obviously things are not the same across different languages, and if you don't embrace the differences you may aswell go back to the previous language and leave things at that.

That said, I am not yet convinced by the DI frameworks I see for scala.

• Guice for example is really a modified java framework (which is fine because scala can use java libs, but because they don't function in the entirely same paradigm of coding languages it feels as though scala's capabilities are not leveraged)
• MacWire annoyed me a bit,because you had to define the dependencies in the files where you used them. Which does not assist in my interface/provider concept.
• SubCut so far seems to be the best suited to what I would expect.

But while going through all of this (and bare in mind this is all in the research phase, I havent used any of them yet) it seemed that DI in Scala is still very scattered, and in its infancy, by that I mean that there are different implementations with different applications, but not one flexible enough or power enough to compare to Symfonys DI. particularly not for my application.

Comments? Thoughts?

Answer 1

My 5 cents:

I have actually stopped using dependency injection frameworks after switching to Scala from Java.

The language allows for a few nice ways of doing it without a framework (multiple parameter lists and currying as well as the mixins for doing injection the way the 'cake pattern' does) and I find myself more and more just using constructor or method parameter based injection as it clearly documents what dependencies a given piece of logic has and where it got those dependencies from.

It's also fairly easy to create different modules sets of implementations or factories for implementations using Scala object s and then selecting between those at runtime. This will give you the guarantee that it wont compile unless there is an implementation available, as opposed to the big ones in Java-land that will fail in runtime, effectively pushing a compile time problem into runtime.

This also removes the 'magic' of how dependencies are created and wired (reflection, runtime weaving, macros, XML, binding context to thread local etc). I think this makes it much easier for new developers to jump into a project and understand how the codebase is interconnected.

Regarding declaring implementations in non-code like XML I have found that projects rarely or never change those files without making a new release so then they might as well be code with all the benefits that bring (IDE support, performance, type checking).