S2Containerを使ったサービス層フレームワーク

S2Containerを利用したサービス層フレームワークを考えてみた。

プレゼンテーション層フレームワークと、パーシステンスフレームワークの間に位置する中間層専用のフレームワーク

ポイント↓

  • 特定のプレゼンテーション層フレームワークに依存しない。
    • StrutsJSFに変更してもサービス実装を変える必要がない。
    • 下位のパーシステンスフレームワークには依存するかもしれないので、DAOインタフェースなどでうまく乗り切る必要アリ。
  • 同一Webアプリ上の同じような機能を持つ複数サブシステム間で、サービス実装を共通化してそのまま利用することができる。
    • 実装は1つで複数の宣言を定義するとかではなく、ルックアップ時にがんばるので、宣言そのものも1つでよい。
  • サービスコンポーネント定義と画面遷移が同一ファイル内で表現できるように。
    • これはStrutsstruts-config.xmlのイメージに近い。画面遷移関係が1ファイルで見渡せるというのはサービス数が多いサブシステムの構築・メンテでは非常に助かる。ツールにかければ簡単に画面遷移関係をビジュアル化できるのがベスト。
  • サービスロケータ等の実装クラスによっては、サービス実装と画面実装だけがあれば良い、限定的configlessを実現できる。
    • サービス実装クラス名や画面ファイル名に規約を設けて、画面内にサービスIDを、サービス実装内に画面IDを直接埋め込むことで依存関係を実装内に埋め込むだけで、両者の関係は規約に基づいて自動的に解決される、というイメージ。あくまでイメージ。柔軟性を犠牲にして、簡単さを向上?

これだけじゃどこにDIを使うかあまりわからんな。


Strutsでいいじゃないかという声が聞こえてきそうだけど、context-pathとディスパッチActionを対応付けるとか、色々目に付くところがあってあまりStrutsにべったりになりたくない*1

好みとして、クライアントからのサービス種別の指定方法とそれに基づいたサービス実装へのディスパッチは柔軟にやりたいし、特定のフレームワークに依存したくないというのがある。

Actionのルックアップ方式の変更なんかはStrutsの拡張でも実現できるかもしれないけど、Strutsに特化するのもイヤンなので、上位・下位に依存しないサービス制御専門の中間フレームワークを考えてみたという次第。

詳しくはまだまとまってないけど、こうやって実際に何かを作ってみると、DIのすごさがわかってくる。Injection時のプロパティ設定によるカスタマイズなんかとても簡単に実現できるし。

あとは、ビューへの依存性をどうやって疎にするかを考えてるところ。
汎用的にするにはJSFも勉強してみないといけないけど、とりあえずJSP前提で考えてみよう。

#ひがさんのブログでは、サービス層がStrutsのActionに吸収されてもいいんじゃないか?というエントリがあったけど、ちょっとそれに逆行してる?

*1:Strutsの機能を一部しか知らないので、設定しだいでできるのかもしれないけど