CRSで業務アプリケーションを構築する場合、HTMLと比較して以下の大きな違いがあります。
CRSファイルは画面レイアウト情報を含みますが、HTMLと異なり必ずしも1個のCRSファイルが１画面に対応することはありません。
WEBサーバとの通信により取得したCRSファイルはHTMLのようにそのまま画面に表示されるのではなく、スクリプトとしてBiz/Browserにより実行されます。実行した結果としてCRSスクリプトの内容により画面が表示されることもありますし、単にデータだけを更新することもあります。
従って、Biz/Designerで画面の要素部品を複数作成し、実行時に結合して１つの画面としたり、共通なロジック部分だけを別のファイルにして結合することも可能です。
また、表示されている画面の一部分だけを変更するようなCRSスクリプトをWEBサーバからダウンロードすれば、画面の一部分だけを変更することも可能です。例えば、TextBox1の背景色を赤に変更する場合、以下のようなCRSスクリプトをWEBサーバが送信することになります。
TextBox1.BgColor = $RED;
Biz/Browserのキャッシュは、ダウンロードしたCRSスクリプトをコンパイルしたバイナリ形式で保存されます。そのために、キャッシュされたCRSスクリプトはコンパイルのオーバーヘッドがなく非常に高速に呼び出すことができます。
また、通常のWEBブラウザと異なりBiz/Browserのキャッシュは、一度キャッシュした内容は明示的に削除しない限り有効です。キャッシュの内容が古くなっていないか確認するための通信も行われません。キャッシュの整合性は、WEBサーバ上で動作するアプリケーションにより保証する必要があります。
このように、Biz/Browserのキャッシュは、「キャッシュ」というよりも、「CRSスクリプトのインストール」と考えたほうが良いかもしれません。
Biz/Browserで業務アプリケーションを快適に利用できるようにするためには、ユーザの操作に対して迅速な応答を返すようにアプリケーションを設計する必要があります。
Biz/Browserには、応答速度を向上させるためのさまざまな機能が内蔵されていますが、最も重要なことはWEBサーバとの通信回数をできるだけ減らすことです。また、通信を行う場合、できるだけ１回の通信で必要なデータを取り出すように心がけてください。通信環境にもよりますが、Biz/Browserが扱うような数10K程度の通信量の場合、処理時間のほとんどをコネクションの接続と切断で占めます。
パフォーマンスが悪化する例
Get("prog1?code=1");
Get("prog2?code=1");
このように必要なデータが２種類ある場合、２個のGET命令で取得すると２倍の時間がかかります。
パフォーマンスを改善する例
prog1とprog2の両方の応答内容を含んだ応答を返すprog3を用意して１回だけの通信に集約します。
Get("prog3?code=1");
これで、パフォーマンスが悪化する例に比べておおむね半分の時間で通信は終了します。