 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||
|
||||||||||||
| どこまでをリッチ化するのか | ||||||||||||
|
最後の点は、これから開発するアプリケーションをどこまでリッチ化するかです。Curlでは主に以降から説明する3つのパターンにより、リッチ指数への深耕度を決めていきます。 |
||||||||||||
| リッチ指数30%：リッチなインターフェースに | ||||||||||||
|
レガシーシステムにおけるフロントエンド（画面）をリッチ化したい場合はユーザインターフェースのリッチ化になります。このケースは画面の見栄えとスムーズな動きを実現し、ユーザに使い勝手の良いインターフェースを提供します。 このリッチ化は、基本的に従来型WebアプリケーションのMVCと同じであり、ビジネスロジックはサーバで行われ、クライアントへは表示する画面が渡されます。  図3：リッチ指数30%の状態 （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||
| リッチ指数50%：画面遷移や入力項目のリッチ化で待機時間の削減 | ||||||||||||
|
上記のリッチ化に加え、画面の遷移や入力項目のチェックなどユーザの操作に関連する部分のリッチ化になります。このケースまでリッチ化すると、画面遷移に要するレスポンスの短縮や親切心溢れたナビゲーション機能の表示などでユーザをリッチな気分にさせることができます。 クライアント側には画面制御のロジックをもち、サーバ側にはビジネスロジックを持ちます。そのため、従来のWebアプリケーションと同様にクライアントがサーバへアクセスできない場合はアプリケーションを使うことができません。  図4：リッチ指数50%の状態 （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||
| リッチ指数100%：オフラインの環境でも利用できるアプリケーションの提供 | ||||||||||||
|
クライアントにビジネスロジック及び画面制御のロジック、また、画面を持ち、サーバはデータベースとのアクセスを行うロジックを持ちます。 リッチ指数100%になると、クライアント側からサービスを提供する複数のサーバへダイレクトにアクセスできるだけではなく、データを取得しているサーバにアクセスできない場合は、フォールトトレランスのようにネットワークアクセスで得ていた機能を切り離し、一部の機能を制限した状態でクライアント上のキャッシュ保存したデータを用いてシステムを継続して利用することができます。 例えば、外出先で社内のサーバにアクセスしてスケジュールを閲覧することができるグループウェアは、従来型のWebアプリケーションではネットワークが繋がらないと参照することができません。 しかしリッチ化度100%で構築したWebアプリケーションであれば、ネットワークが切断されていても、クライアントPCにあるグループウェアを起動し、キャッシュに保存してある直前までのスケジュールをみることができます。  図5：リッチ指数100%の状態 （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
