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