ひがやすを技術ブログ

電通国際情報サービスのプログラマ

Seasar2.4のパッケージ構成

Seasar2.4では推奨のパッケージ構成があります。推奨のパッケージ構成を決めた理由は2つあります。
1つめは、プロジェクトのメンバの知識を共有すること。ある機能を持ったクラスは、どのパッケージに配置するのかあらかじめ決まっていると、直ぐに目的のクラスを探すことができるようになります。
2つめは、パッケージ構成を決めることで、フレームワークやツールがいろいろと作業を自動化できることです。例えば、HOT & COOL deployでは、このパッケージ構成にもとづいて自動的にコンポーネント探してをコンテナに登録します。
もちろん、推奨のパッケージ構成を使わずに自由に決めることもできます。その場合は、HOT deployは使えませんが、Seasar2.3の自動登録は、そのまま使うことができます。
パッケージの構成パターンは2つあります。
1つめは、ルートパッケージ + 個別パッケージの構成です。例えば、examples.chura.logic, examples.chura.daoというパッケージの場合、examples.churaがルートパッケージ、logicやdaoが個別パッケージになります。
もう1つのパターンは、ルートパッケージ + web + サブアプリケーションの構成です。例えば、足し算のサブアプリケーションのパッケージは、examples.chura.web.addになり、addがサブアプリケーションに相当します。
サブアプリケーションとは、1つのアプリケーションを幾つかの論理的な固まりに分割したものです。複数の関連のある画面を一つにまとめたものと言ってもよいでしょう。
サブアプリケーション固有のものはサブアプリケーション配下に置き、複数のサブアプリケーションで共有されるものは個別パッケージに置くというのが、2つのパッケージ構成をとっている理由です。
サブアプリケーションに置かれるのは、

で、個別パッケージに置かれるのが

  • Entity
  • Dao
  • Logic
  • Validator
  • Converter
  • Interceptor
  • Dto
  • Dxo(共通的に使われるDxo)
  • Helper
  • Util

です。ActionやServiceがなくなっていたり、Helperのような見慣れないクラスがいるのですが、その辺は、これから説明します。