ルール指向アプローチでは、ビジネスロジックを次の3要素に分けて考えます。
アクションは、フロー制御を含まない最も粒度の細かいロジックです。
NazunaのRuletとして実装します。
フロー制御は、アクションをどのような順番でどのような条件のときに実行するのかを制御します。
フロー制御がネストすることもありえます。
NazunaのFlowletとして実装します。
モデルは、ビジネスロジックを流れるデータです。
JavaBeansとして実装します。
モデルを元にER分析を行い、データベースの構造を決めます。
機能からデータベースの構造を決めるのではなく、モデルを分析して
データベースの構造を決めるため、機能の変更による影響を受けにくくなります。
クラスの抽出などという難しいことは考えずに、クライアントが必要とするデータ構造を
JavaBeansにすると良いでしょう。
テーブル設計がきちんとできていれば、JavaBeansとRDBMSとのマッピングは、
NazunaのSqletを使って簡単に行えます。
Nazunaの基本的な構成要素は、次の3つです。
JSPのビジネスロジック版だと考えるとわかりやすいでしょう。
ビジネスロジックの構成要素を直接マッピングできるので、
顧客の要求をシームレスに実装できます。
フロー制御を含まない最も粒度の細かいロジックです。
クライアントから最初に要求があったときに、Javaのソースファイルがコンパイルされ
インスタンス化されます。
以後要求はそのインスタンスに対して送られます。
システムの稼動中に、ソースファイルが書き換えられると自動的に再コンパイルされ
インスタンスが置き換わります。
Ruletをどのような順番でどのような条件のときに実行するのかを制御します。
他のFlowletを呼び出すこともできます。
クライアントから最初に要求があったときに、XMLファイルがコンパイルされ
インスタンス化されます。
以後要求はそのインスタンスに対して送られます。
システムの稼動中に、XMLファイルが書き換えられると自動的に再コンパイルされ
インスタンスが置き換わります。
O/Rマッピングを行います。
クライアントから最初に要求があったときに、XMLファイルがコンパイルされ
インスタンス化されます。
以後要求はそのインスタンスに対して送られます。
システムの稼動中に、XMLファイルが書き換えられると自動的に再コンパイルされ
インスタンスが置き換わります。
FlowletのようにXMLファイルにロジックを記述し、実行時にSQL文を動的に組み立てることもできます。
Flowletもプログラミング言語として必要な機能はそろっています。
それではなぜ、Ruletが必要なのでしょうか。
RuletはJavaで記述されているため、Eclipse等のIDEでの様々な支援機能の活用や
コンパイル時のチェックなどにより、実行する前にかなりの問題を避けることができます。
それに対しFlowletは、まだIDEでの支援機能が開発されていないため、
コーディングが主体となるロジックの記述はRuletの方が優れています。
Ruletもフロー制御を記述できます。
それではなぜ、Flowletが必要なのでしょうか。
FlowletはXMLで記述されているため、構造が明確で、処理の流れが把握しやすくなります。
仕様をXMLで記述すると、そのまま実行できるというのは魅力的です。
言語がJavaであるRuletに比べ、フロー制御がが主体となる場合は、Flowletの方が優れています。