ひがやすを技術ブログ

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

EJB3時代のアーキテクチャパターン 業務ロジックType5

goya

一般的なEJB3時代のアーキテクチャはType4で十分だと思います。でも、EJB3って開発が重いよね。修正するたびに、パッケージング化して、アプリケーションサーバにデプロイしないと、実際に動かしてみることできないって耐え切れない。
でも大丈夫。Seasar2では、HOT deployの機能を提供しています。HOT deployとは、ソースを変更したときに､アプリケーションサーバのリブート無しにその変更が即座に認識される技術です。このデモをみると、直ぐにどんな技術か理解できるでしょう。
Type4をベースにHOT deployを適用できるようにしたのがこのTypeになります。

  • Type5:EntityLogicに業務ロジックを書く

Entityに業務ロジックを書いた場合、業務ロジックの変更をHOTに認識することができません。なぜなら、Entityを管理しているJPAのフレームワークは､HOT deployに対応していないからです。現在、Seasarファウンデーションでは､HOT deployに対応したJPAの実装であるKuinaを開発していますが､完成は､2007年の初め前後になりそうなので、今使うとなるとEntityではHOT deployを利用できないのです。
そのため、EntityにあるロジックをすべてEntityFacadeに移したのがこのTypeです。ロジックはすべてEntityFacadeにあるので、名前もEntityLogicに変更してます。
また、Seasarでの開発の場合､プレゼンテーションモデルを使うことが推奨なので､プレゼンテーションモデルとS2Dxoを使っています。

  • Page(プレゼンテーションモデル + プレゼンテーションロジック)
  • Dxo(データ交換ロジック。PageにDI)
    • S2Dxoを使う。インターフェースを書くだけでよく､実装は必要ない。
  • EntityLogic(業務ロジック。PageにDI)
  • Dao(業務ロジックにDI)
    • KuinaDaoを使う。インターフェースを書くだけでよく､実装は必要ない。したがって、EntityManagerも気にしなくても良い。
  • Entity

開発者が書く必要があるのは､Page、Dxoのインターフェース、EntityLogicのインターフェース、EntityLogicの実装、Daoのインターフェースです。ただし、実際はEntityLogicの実装以外は､ツールで自動生成する予定なので､開発者のコーディングは激減するはずです。また、テストコードの雛型も自動生成する予定です。
Viewテンプレートは､HTMLになります。いちいち、JSPに変換する必要もありません。HTMLの動的に変えたいタグに、対応するEntityのプロパティ名を設定し、anchorタグやsubmitタグにイベント名を指定するだけで、後は､ソースコードが自動生成されます。残りは､EntityLogicの実装を書くだけです。
ソースコードが自動生成されるだけではありません。Entity以外は､HOT deployに対応しているので､余分な待ち時間は必要なくさくさく開発できます。
Entityに修正が入る場合､それは、テーブルのレイアウトが修正されるのとほぼ同様の意味になります。その場合､スキーマやデータの移行もツールでサポートします。
このアーキテクチャの場合､開発手順は次のようになります。実装に近い部分の説明をします。

  1. HTMLのモックを作成する。
  2. HTMLのモックより､業務項目を洗い出して､データベースのスキーマを作成する。
  3. スキーマより､Entityを自動生成する。
  4. HTMLのidにプロパティ名とイベント名を設定する。
  5. Page、Dxo、EntityLogic、Daoを自動生成する。
  6. EntityLogicの業務ロジックを実装&テストする。

このサイクルをHOT deployとDBスキーマ・データ移行がサポートします。設定ファイルも書く必要がありません。開発の最初に基本的な情報を記述するだけです。
Type5の変形として､Pageからプレゼンテーションロジックを分離し､データ交換ロジック(Dxo)をServiceに持っていったのが次のパターンです。

  • Page(プレゼンテーションモデル)
  • Action(プレゼンテーションロジック)
  • Service(ActionにDI)
  • Dxo(データ交換ロジック。ServiceにDI)
    • S2Dxoを使う。インターフェースを書くだけでよく､実装は必要ない。
  • EntityLogic(業務ロジック。ServiceにDI)
  • Dao(業務ロジックにDI)
    • KuinaDaoを使う。インターフェースを書くだけでよく､実装は必要ない。したがって、EntityManagerも気にしなくても良い。
  • Entity

ちょっとクラスは増えますが､それぞれのクラスが1つの役割に徹していて、個々のクラスのソースは最も単純になるでしょう。
これで、一通り基本的なアーキテクチャについて説明しました。