Spring-bootにてHttpServletRequestにアクセスする２つの方法（コントローラ引数 v.s. DI）の相違点について

Question

前提・実現したいこと

Spring-Bootを使用したCMSの開発を行っています。

プログラムからrequestやresponse、sessionの情報にアクセスする場合、
0. RequestMappingされた関数（メソッド）の引数として受け取る
0. 使用するBeanにDIする

の2つの方法がとれると思いますが、これらの動作上の相違点はありますでしょうか？
開発中のシステムの特性上、できれば後者の方法を取りたいのですが、社内に後者の方法をとった事例がなく、注意点などあればご教示いただきたいです。

@Controller
class PageController {

    // RequestMappingされた関数（メソッド）の引数として受け取る
    @RequestMapping("/page")
    fun getPage(
        request: HttpServletRequest,
        response: HttpServletResponse,
        session: HttpSession
    ): ModelAndView? {

    // 以下略

@Controller
class PageController(
    // 使用するBeanにDIする
    var request: HttpServletRequest,
    var response: HttpServletResponse,
    var session : HttpSession
) {

    // 以下略

なお、後者の方法を取りたい理由は、システムの特性上ControllerだけでなくService等のbeanからもrequest/response/sessionにアクセスしたいケースが多く、Controllerで取得した情報を各beanに引き回すことを避けるためです。

試したこと

一応、上記両方の方法で動作することを確認しています。
後者の方法では、
・RequestContextHolder.currentRequestAttributes().getRequest()
・RequestContextHolder.currentRequestAttributes().getResponse()
で取得したrequest/responseを使っていて、それが前者の方法で引数から受け取ったオブジェクトと同じものであることはわかりましたが、どこの設定でそのような動作になるのかまでは突き止めていません。

試したこと（追記）

「同時アクセスしたらわかるのではないか」と指摘をいただきましたので、実験してみました。

package test

import org.springframework.stereotype.Controller
import org.springframework.web.bind.annotation.RequestMapping
import java.util.*
import javax.servlet.http.HttpServletRequest

@Controller
class PageController(val requestD: HttpServletRequest) {

    @RequestMapping("/page")
    fun getPage(requestA: HttpServletRequest): String? {

        // ランダム値とハッシュコード
        val hashCode = this.hashCode()
        val uuid = UUID.randomUUID().toString()
        println("初期：$uuid  hashCode：$hashCode")

        // ランダム値をsessionに格納
        requestA.session.setAttribute("test", uuid)

        // 1000ミリ秒間隔で一致確認
        for (i in 1..5) {
            Thread.sleep(1000)
            val a = requestA.session.getAttribute("test") as String
            val d = requestD.session.getAttribute("test") as String
            val compare = if (a == d) "一致" else "不一致"
            println("引数：$a  ＤＩ： $d  $compare")
        }
        return null
    }
}

以下、二つのブラウザからなるべく同時にアクセスした際のコンソールです。

初期：1bc4c09e-383b-4b4f-a029-ce6e42c971cb  hashCode：81445899
初期：231966be-a4c7-4451-9550-f75ad637782e  hashCode：81445899
引数：1bc4c09e-383b-4b4f-a029-ce6e42c971cb  ＤＩ： 1bc4c09e-383b-4b4f-a029-ce6e42c971cb  一致
引数：231966be-a4c7-4451-9550-f75ad637782e  ＤＩ： 231966be-a4c7-4451-9550-f75ad637782e  一致
引数：1bc4c09e-383b-4b4f-a029-ce6e42c971cb  ＤＩ： 1bc4c09e-383b-4b4f-a029-ce6e42c971cb  一致
引数：231966be-a4c7-4451-9550-f75ad637782e  ＤＩ： 231966be-a4c7-4451-9550-f75ad637782e  一致
引数：1bc4c09e-383b-4b4f-a029-ce6e42c971cb  ＤＩ： 1bc4c09e-383b-4b4f-a029-ce6e42c971cb  一致
引数：231966be-a4c7-4451-9550-f75ad637782e  ＤＩ： 231966be-a4c7-4451-9550-f75ad637782e  一致
引数：1bc4c09e-383b-4b4f-a029-ce6e42c971cb  ＤＩ： 1bc4c09e-383b-4b4f-a029-ce6e42c971cb  一致
引数：231966be-a4c7-4451-9550-f75ad637782e  ＤＩ： 231966be-a4c7-4451-9550-f75ad637782e  一致
引数：1bc4c09e-383b-4b4f-a029-ce6e42c971cb  ＤＩ： 1bc4c09e-383b-4b4f-a029-ce6e42c971cb  一致
引数：231966be-a4c7-4451-9550-f75ad637782e  ＤＩ： 231966be-a4c7-4451-9550-f75ad637782e  一致

引数のリクエスト（requestA）から取得したセッションの値と、DI（コンストラクタインジェクション）したリクエスト（requestD）から取得したセッションの値が常に一致していますので、DIされたHttpServletRequestはスレッドセーフであることがわかりました。

補足情報（FW/ツールのバージョンなど）

spring-boot:ver 2.1.7
Kotlin:ver 1.3.50

Comments

[退会済みユーザー]

二つの端末から同時アクセスをするとわかるかもね

[yusuke0]

ご指摘ありがとうございます。

DIされたHttpServletRequestがスレッドアンセーフではないかというご指摘でしょうか？
質問に追記しましたとおり、スレッドセーフです。

それとももっと厳密な同時アクセスについて指摘されていますか？
そうだとすると、今わかっている情報だけで「やってみる」のは困難です。
何か競合して問題を起こす可能性がある部分をご存知でしたら、ご教示いただけると幸いです。

[退会済みユーザー]

後ひとつ、 ControllerオブジェクトのhashCode って一緒にだせます？
（セキュリティ上の問題で Koltin インストールできんので）

[yusuke0]

これでいいでしょうか？
hashCodeは一致です。

Answer 1

英語のサイトで同様の質問を見つけました。
一旦こちらの内容で自己解決としたいと思います。

@Autowired HttpServletRequest vs passing as parameter - best practice

Both are ok.

とのこと。
ソースとなるドキュメントへの参照をご存知の方がいれば、上記の質問に追記いただけるとありがたいです。

Answer 2

以下のサイトが参考になるかと思います。

• Spring FrameworkでDIする3つの方法
• SpringでField InjectionよりConstructor Injectionが推奨される理由

【追記】
私見ですがHttpServletRequest等をControllerで受け取るのはfunctionとすべきだと考えます。
BeanとしてDIするのはそのクラスの振る舞いに必要な依存性を注入するべきであって、
ユーザのリクエスト毎にControllerを生成してHttpServletRequest等を注入するのは違和感を覚えます。

今回の質問でControllerのConstructor に指定して、セッションごとに処理を分けることができることを初めて知りました。リクエスト毎に毎回Controllerのインスタンスを生成するのは非効率な気もしますが、活用方法があるのかもしれません。

Comments

[yusuke0]

回答ありがとうございます。
コンストラクタインジェクションが推奨されていることは理解できました。
今後はなるべくコンストラクタインジェクションに切り替えていこうと思います。

ただ、今回知りたかったのは、「３種類のDI方法の比較」ではなく、「HttpServletRequest等について、コントローラの引数として受け取る方法と、DIする場合の違い」でした。
こちらについても、情報をお持ちでしたらご教示いただけると幸いです。

質問内容の方は「引数 v.s. @Autowired」だと誤解を招くのでその部分の訂正と、サンプルコードをコンストラクタインジェクションに訂正しました。

[yusuke0]

追記ありがとうございます。

> 私見ですがHttpServletRequest等をControllerで受け取るのはfunctionとすべきだと考えます。

そうですね。それは同意です。
ただ、例外的にController以外のBeanでHttpServletRequest等にアクセスしたい場合、HttpServletRequest等をそのBeanにDIすることが大丈夫かどうか知りたかったのです。

> リクエスト毎に毎回Controllerのインスタンスを生成するのは非効率な気もしますが、活用方法があるのかもしれません。

こちらですが、Controllerのインスタンスはspring-bootの起動時に１つ作られるだけで、リクエスト毎にはつくられません。
asahina1979さんへの回答で質問に追記した通り、同時アクセスした場合のControllerインスタンスのハッシュ値は同一です。
同一インスタンスでありながらスレッドごとに別のリクエスト情報にアクセスできるのは、DIされたHttpServletRequestのインスタンスは実はプロキシ（？）で、そのメソッドを実行する際、springframeworkがThreadLocalから正しいリクエストを取得しているからのようです。