|
|
 |
 |
 |
 |
- MVCアーキテクチャの採用によるビジネスロジックのコンポーネント化
- cFrameworkはSun
Microsystemsより公開されているBluepintsのデザインを踏襲し,その中で推奨されているMVCアーキテクチャを採用しています。MVCアーキテクチャはSmalltalkにおいてGUIのアプリケーションを構築するためのパターンとして考案されたものですが,ModelをViewとControllerから分離して,Modelの再利用性を高めようとする考え方は,実装技術に依存することなく,Webベースのシステムに対しても有効です。MVCアーキテクチャは,コンポーネントの再利用を促進していくうえで最適なアーキテクチャパターンのひとつです。
- Web層とEJB層の分離
- cFrameworkはシステム全体がWebサーバ(サーブレットコンテナ)とEJBサーバ(EJBコンテナ)に分散配置ができるように考慮しています。Web層ではブラウザからのリクエストの受付,EJB層へのリクエストオブジェクト(イベントの生成),EJB層へのリクエスト,次画面の決定,画面遷移を大きな役割としています。EJB層ではクライアントのタイプ(ブラウザかJavaアプリケーションかアプレットかなど)を意識することなく,ビジネスロジックを実行するという役割を担っています。
- ハンドラの組み込みによるシステムの構築
- EJBを利用するWebベースのシステムでは,HTTPリクエストからのパラメータの取得やEJBHomeクラスのlookup,画面遷移の制御など共通に利用できる部品を揃えることにより,設計・開発の省力化を図ることが可能です。この"共通に利用できる部品"をcFrameworkとして準備し,ターゲットのシステムごとに異なる部分を各種ハンドラで実装していくというスタイルを採用しています。ハンドラベースによる開発スタイルはクラス設計を画一化し,品質の均等化が図れます。
- ベースコンポーネントとパッケージコンポーネント
- cFrameworkでは,再利用の機会を広げる意味からベースコンポーネントとパッケージコンポーネントという考え方を採用しています。これはドメインのエンティティを表現したオブジェクト(ベースコンポーネント)と,そのオブジェクトを呼び出すコントローラ的な役割を持つオブジェクト(パッケージコンポーネント)では,再利用の機会が異なるはずであるという考えに基づいたものです。ベースコンポーネントという細粒コンポーネントは再利用の機会が広がる分,再利用時のコントローラ系の開発工数が増大します。一方,処理の流れまで記述してあるパッケージコンポーネントレベルでの再利用は,要求仕様との違いにより再利用の機会が狭まりますが,適用できた場合の工数削減は大きいでしょう。このように複数の再利用レベルを設定することにより,柔軟な再利用方法を提供することができます。
- 軽量なWebアプリケーションの構築をサポート
- cFrameworkはEJBを利用しないWebアプリケーションを構築することも可能です。特に照会系のシステムで,コンポーネント化の必要がない場合は,EJB層へのリクエストをおこなうことなくMainServletとView(JSP)のみで動作できるように構築されています。また,EJB層へのリクエストをおこなう場合とおこなわない場合との違いをできる限りなくし,どちらのパターンでもHTTPセッションやHTTPリクエストに保管したオブジェクトをViewが自律的に照会するように設計されています。
- 複数のアプリケーションサーバのサポート
- cFrameworkはアプリケーションサーバの違いを吸収し,複数のアプリケーションサーバで同じバイトコードで稼動させることができます。理論上,J2EE準拠のアプリケーションサーバ間ではポータビリティが保証されるわけですが,実際動作させるには様々な障害があります。cFramework
V1.5.4ではWebLogic Server, iPlanet Application Server,
Cosminexus,WebSphere, Bluestoneで稼動できることを確認しています。
|
 |

| |