将依赖注入和继承与Play 2.5相结合

Question

在我将App从2.4迁移到2.5的过程中(并去掉了所有的静态引用)，我做了以下工作：

class Generic @Inject()(implicit val mat: Materializer, cache: CacheApi, wsClient: WSClient, configuration: play.api.Configuration) 
{ ... }

@Singleton
class Concrete1 @Inject() (gw:Generic) { ... }

@Singleton
class Concrete2 @Inject() (gw:Generic) { ... }

为了使用它，我用Generic的实例注入了Concrete1/2。它是有效的，但在网上看过其他几个例子后，它似乎不太正确。

我正在考虑这样修改它：

    abstract class Generic(cache: CacheApi, wsClient: WSClient, configuration: play.api.Configuration) 
    { ... }

    @Singleton
    class Concrete1(cache: CacheApi, wsClient: WSClient, configuration: play.api.Configuration) 
       extends Generic(cache, wsClient, configuration) { ... }

    @Singleton
    class Concrete2(cache: CacheApi, wsClient: WSClient, configuration: play.api.Configuration) 
       extends Generic(cache, wsClient, configuration) { ... }

然后为了能够做：@Inject() (c1:Concrete1, c2:Concrete2)，我想我需要它们是https://www.playframework.com/documentation/2.5.x/ScalaDependencyInjection#Programmatic-bindings定义的模块？在这里做什么更有意义？

Answer 1

实际上，我不同意你“看起来不太正确”的说法。

我认为您的第一个示例更贴切地反映了基于继承的组合哲学，这种哲学已经成为构建软件的accepted as a more maintainable way。

在对Concrete或Generic类一无所知的情况下，很难说更多，但如果后者(基于继承的结构)更容易对进行适当的单元测试，我会感到非常惊讶，而模拟Generic并注入它来测试Concrete类将是微不足道的。

其他好处：

与Play框架捆绑在一起的declaration

• less
• 不太嘈杂/重复(不需要模块灵活性(当您的具体类共享第二个“公共”类时)