ThreadLocalの使い方

Java

プレゼン層周りを独自フレームワークというか既存フレームワークの使い方というか、ある程度の機構を固めるとする。

でも、ユーザの属性はアプリケーションごとに異なるだろう。
Map形式で拡張属性を持たせてもいいけど、キーの管理が必要になり、面倒。
それに、例えばサブシステムという概念を導入して、今は○○サブシステムに対するリクエストだ…、というようなコンテキストが必要なアプリケーションもあるだろう。

この辺りの柔軟性を確保するために以下のような案を考えてみた。

  • User、Subsystemなどはアプリケーションごとに独自実装する。
  • これらの情報は、ServletFilterで作成or取得して、ThreadLocalに格納する。
  • Action,Serviceでは必要に応じてThreadLocalからこれらのコンテキスト情報を取得する。

懸念事項:

  • グローバル変数という悪しき習慣の復活？
  • ビジネスドメイン層にはコンテキストという概念を持ち込んではいけない。
    • ThreadLocalへのアクセスを実装上できないようにするか、規約として禁止する。
    • 前者の場合、パッケージ階層とpolicyなどで強制できそうだが、そこまでする必要はないだろう。
  • っていうか、本当に動くの？