 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| モデルとビューの統合 | ||||||||||
|
続いて、モデルとビューの統合を行います。統合に必要となる作業は次の3つです。
表1：統合までの手順 では、この順に作業を進めていくことにしましょう。 |
||||||||||
| サービスクラスの実装 | ||||||||||
|
サービスクラスは、ビューに依存する部分とロジックに依存する部分を貼り合わせる役割を担うものです。 この占いアプリケーションでは「占う」ボタンのクリックで呼び出されるアクションメソッド（doFortuneTelling()メソッド）、「占う」アクションの結果を返すゲッターメソッド（getResult()メソッド)、「他の人を占う」ボタンのクリックで呼び出されるアクションメソッド（doRetry()メソッド）の3つを実装します。 これまでに登場した2つのクラスとサービスクラスとの関係をUMLで表したものを図1に示します。  図1：クラスの関係図 サービスクラス（FortuneTellingService.java）のソースコードはリスト1のとおりです。このソースコードは「Model」プロジェクトではなく、「ViewController」プロジェクトのほうに追加します。 リスト1：FortuneTellingService.java  （画像をクリックすると別ウィンドウに拡大図を表示します） ソースコードで注目すべき点は、アクションメソッドの戻り値です。JSFの仕様では、アクションメソッドは遷移ケースIDを文字列として返すことが期待されているので、アクションの結果に即したものを返します。 今回の占いアプリケーションでは、tellFortune()メソッドによって例外が発生するような失敗ケースはないので、doFortuneTelling()アクションメソッドは単純に「show result」という遷移ケースIDを返します。同様に、doRetry()アクションメソッドも遷移ケースID「retry」を返しています。 ほかには、FortuneTellerクラスやUserInfoクラスのインスタンスをFortuneTellingServiceクラス内で生成せず、setFortuneTeller()／setUserInfo()の両セッターで受け取ったものを使っているところにも注目してください。実は、これらのインスタンスはJSFによって管理（マネージ）され、デプロイ時にセッターを通じてインスタンスが与えられるようになっています。 これにより、サービス（FortuneTeller）や、画面で入力された値を格納したBean（UserInfo）が、FortuneTellingServiceに自動で与えられることになり、インスタンス生成や値の型変換などの処理が不要となり、クラス間の依存関係が少なくなります（注3）。
※注3：
アプリケーション内のクラスの依存関係がアプリケーションオブジェクトを保持する側（JSFコンテナ）によって決定されることから、このような実装パターンは依存性注入（Dependency Injection）と呼ばれます。JSFはDIコンテナとしての性格も持っているといえるでしょう。
|
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
