TERASOLUNAフレームワークって何をしてくれるの？
TERASOLUNAフレームワークは、プレゼンテーション層にStrutsを、オブジェクト間の依存性の管理にSpring（DIコンテナ）を、O/RマッピングツールにiBATISを使用したフルスタックフレームワークです。
その特徴として、Strutsではサポートしていなかった業務ロジック周りの処理基盤を提供していること、Springで提供しているアスペクト指向プログラミング（AOP）の機能により、ログ出力、トランザクション処理といった本質的でない処理をビジネスロジックから取り除いたことなどが挙げられます。
編集部注：Spring Framework（DIコンテナ）やAOPについて詳しく知りたい読者は、インデックス「DI×AOP（Spring／Seasarなど）」を、O/Rマッピングについては記事「O/Rマッピングの役割とメリット」を、それぞれご覧ください。
TERASOLUNAフレームワークの3つの狙い
TERASOLUNAフレームワークの狙いは、大きく分けると下記の3点であるといえます。
- 分業化の促進
- セッション管理の不要化
- DB、トランザクション処理の簡素化
これら3点の詳細について、解説していきましょう。
【1】分業化を促進するアーキテクチャ
TERASOLUNAフレームワークは、リクエスト処理単位での分業化ができるようにアーキテクチャが設計されています。
変数管理が容易
業務開発者リーダーは「blogic-io.xml」と呼ばれる業務ロジックの入出力定義ファイルを記述します。各業務開発者は、POJOもしくはMapの業務入出力オブジェクトを定義し、業務処理メソッドの定義されたBLogicインターフェイスを継承して業務ロジックを実装します。
入出力情報をblogic-io.xmlに集約することにより、変数管理が容易になり、また、業務ロジックの独立性が高まりました。業務開発者は、blogic-io.xmlを基にリクエスト処理の実装を並行作業で進めることができ、開発の生産性が高まります。
アクションクラスを実装する必要がない
TERASOLUNAフレームワークでは、アクションクラスを実装する必要はありません。フレームワークが用意している「BLogicAction」というアクションを利用することにより、セッションからオブジェクトへの詰め替え処理、業務呼び出し処理、反映処理を自動的に行います。業務開発者が行っておくべきことは、blogic-io.xmlの記述と、呼び出す業務を設定ファイルに記述することだけになります。
自由は奪わない
一方で、業務処理が「セッションIDを取得する」などといったプレゼンテーション層依存のコードを含む場合は、BLogicActionを拡張して業務処理の前後にプレゼンテーション層依存のコードを挿入する、アクションのみで実装することで、対応できます。規約から外れなければ実装できない例外的な業務処理についても実装できる、「自由は奪わない」フレームワークであるといえます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
＜set-property＞タグでは、業務で使う変数名とアクションフォームのプロパティ名との対応を記述しています。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
BLogicResultは業務出力オブジェクトと遷移先情報を格納するクラスとなります。
【2】不要になったセッション管理
TERASOLUNAフレームワークは、不要になったスコープ（セッションスコープ）のオブジェクトを自動的に削除します。
“業務スコープ”の変数を定義できる
TERASOLUNAフレームワークには、先頭に「_」が付く名前のアクションフォームをセッション中に1個しか持たないように、新しいアクションフォームの生成時に古いアクションフォームを削除する機能があります。これを利用し、一連の業務の中で使われる変数については、業務にひも付く「_」付きの名前で定義したアクションフォームに定義しておくことで、別業務に移った際に一斉にセッションから削除できます。
別のいい方をすれば、「“業務スコープ”の変数を定義できる」ということになります。
次ページでは、TERASOLUNAを用いたDB接続／トランザクション処理について解説していきます。
Copyright © ITmedia, Inc. All Rights Reserved.