Play 2.4 と Dependency Injection
Play 2.3 が出たばっかで 2.4 の話をします。
前置き: Scala での DI
Scala では DI についてのベストプラクティスと言える方法はなく、まだ意見が分かれている状態です。大きく割ると DI コンテナなどを使った動的な DI と、cake pattern, implicit parameter, macro, reader monad などを利用した静的な DI の 2 パターンです。
動的な DI と静的な DI にはそれぞれメリットとデメリットがあります。動的な DI のメリットは Java のわりと優秀な DI コンテナ (Guice とか) が使えて比較的取っ付きやすいこと、デメリットは型安全ではないところ。静的な DI のメリットは型安全、デメリットは trait だの macro だの implicit parameter だの、コンパイル時間が伸びる要因満載であることです。
- 実戦での Scala: Cake パターンを用いた Dependency Injection (DI) | eed3si9n
- Dependency injection in Scala with Play 2: it’s free | Julien Richard-Foy
- Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad - Originate Developer Blog
- Careful Escapades: Using implicit parameters for Dependency Injection in Scala
また静的な DI を行うとコードが少し複雑になってしまう傾向もあります。私は良く cake pattern で DI をしていますが、いくつもの trait を組み合わせてオブジェクトを組み立てていくと実装がばらけてしまい、コードが追いづらくなるという批判は納得しています。オブジェクトの継承関係が複雑になると、初期化順でハマったりもします。implicit parameter や reader monad による DI はあまりしませんが、まあ多くの開発者はそんなフレンドリーとは受け取ってくれないでしょう。
型安全好きな Scala コミュニティとしては当然静的な DI が良いよねと言いたいんでしょうが、現状はいろいろ問題があるので、DI は定期的によく盛り上がる(燃え上がる)話題の一つです。
Play 2.4 の DI
Play には DI の機能は一部あるものの、まだ本気ではない感じです。 そんな中 play-framework dev(開発者 ML) に、James Roper さんから DI の話題が投下されました。
Play 2.4 - Dependency Injection
要旨をまとめると
- Play としては DI を動的に行うのか、静的に行うのか、どちらか一方の立場を取るつもりはない。ただしドキュメントに載せるなら動的な方法が良い気がする。
- Play 2.4、そして Play 3.0 では constructor injection を基本にしたい
- play.api.Play.current が状態を持たせるよりも constructor injection を基本にしたほうがテスタビリティは上がるだろう
constructor injection と言ってるのはまあこんな感じです。
class MyController(wsClient: WSClient) {
wsClient.url(...)
}
constructor で WSClient という依存性を渡しています。まあ普通っすね。普通っぽいですが、これができると Play ではかなりテストがしやすくなります。
現状では Play の各モジュールは play.api.Application というグローバルな状態を持つクラスにべったりと依存しています。ピンとこない人に説明すると、良く何も考えずに import しているあれです。
import play.api.Play.current // これが play.api.Application のインスタンス
設定などアプリケーションの情報はこのインスタンスがなんでもかんでも持っています。そのため、Play のテストではこの Play.api.Application の Fake を作ってあげる必要があります。サードバーティプラグインを使ったり、データベースの設定を変えたり、ちょっと凝ったことをやりたくなるとこれがなかなかめんどくさい。
// Play のドキュメントから class ExampleSpec extends PlaySpec with OneAppPerSuite { // Override app if you need a FakeApplication with other than // default parameters. implicit override lazy val app: FakeApplication = FakeApplication( additionalConfiguration = Map("ehcacheplugin" -> "disabled") ) "The OneAppPerSuite trait" must { "provide a FakeApplication" in { app.configuration.getString("ehcacheplugin") mustBe Some("disabled") } "start the FakeApplication" in { Play.maybeApplication mustBe Some(app) } } }
グローバルなオブジェクトに状態を持たせるのは、良くないなあと思いつつも、実際 Web アプリの場合はこういうグローバルなものがあったほうがやっぱり便利かなと思ってしまうこともあるのでよくわかりません。ただそういう設計ではやっぱりテストしづらいよね。もっとシンプルな Constructor Injection を基本にしたフレームワークにしてテストをもう少し楽に書けるようにしようね、というのが Play 2.4 そして Play 3.0 の方針だそうです。
実際どのような DI の方式が採用されるのか、どのくらいの規模の変更になるのかは知りませんが、Play 2.4、Play 3.0 のことを考えるならあまり play.api.Application(play.api.Play.current) に頼ったコードは書かないよう気をつけていたほうが移行が楽になるかもしれません。
いやあしかしすでにもう Play 3.0 の話題が出る時期なんですね。