Question

在我将应用程序从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

我实际上不同意你的＆＃34;看起来不太正确＆＃34;言。

我认为你的第一个例子更贴切地反映了构成而不是继承哲学已经accepted as a more maintainable way来构建软件。

在不了解您的Concrete或Generic课程的情况下，很难说更多，但如果后者继承，我会非常感到惊讶基于结构，更容易正确单元测试，而模拟Generic并将其注入测试Concrete类将是微不足道的。

其他好处：

少嘈杂/重复宣言
与Play框架相关联（不需要模块定义）
未来的灵活性（当您的具体课程分享第二个＆＃34;普通＆＃34;课程时）

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

1 个答案: