Spring プレゼンテーション層 - お勉強メモ

プレゼンテーション層ではSpringのMVCフレームワークが利用可能

Springが提供するMVCフレームワークの構成

• アプリケーションコントローラであるアプリケーションコントローラサーブレット
• コントローラサーブレットから呼ばれるコントローラクラス
• その動作を制御する定義ファイル

これらを利用することによってUIとしてJSPだけでなくVelocityやXSLTなどを利用することが可能。

アプリケーションコントローラの1つであるコントローラクラスはSpring　MVCフレームワークが提供するクラスを継承して開発者が提供する。

Spring　MVCフレームワークを利用した場合、コントローラクラスはユーザからの入力データをWebコンテナに依存しないJavaBeansで取得でき、Webコンテナから分離された入力データの検証クラスを利用することができるのが利点。
またコントローラクラスからサービスロジックを呼び出すには、DIコンテナからサービスロジックを取得して行わなければならない。これによりアプリケーションコントローラに不用意にサービスロジックを組み込む可能性が低くなる。

---

SpringWebインテグレーション機能

MVCフレームワークを必ず使う必要はない

Springを利用してWebアプリケーションを作るときに必要な機能
Webインテグレーション機能を使えばUIの技術であるVelocityやMVCフレームワークであるStrutsを簡単にプラグインして利用することが可能

---

ビジネス層
Springがビジネス層に提供する機能はDIコンテナとAOP

DIコンテナとサービス、ドメイン
サービスおよびドメインクラスはPOJOとして実装される(分散システムでないかぎりEJBを利用することはない)

DIコンテナを利用した場合に特徴的な設計

• プレゼンテーション層のアプリケーションコントローラがサービスクラスを直接知らないようにすること

→アプリケーションコントローラは必ずDIコンテナを通してサービスクラスを取得してサービスロジックを利用するようにする。このときアプリケーションコントローラが取得するサービスクラスはI/Fとして取得する。つまりI/Fベースのやり取りを行うことが重要。

• サービスクラスがデータアクセス層のデータアクセスフレームワークを直接知らないようにすること

→サービスクラスからデータアクセスクラスの利用も同様にDIコンテナからI/Fベースで行う。

これにより隠そうの結びつきを緩くし、層の独立性を高め、変更の局所化が実現できる。

勘違いされやすいところ
DIコンテナはValueObjectのライフサイクル管理は行わない。
ValueObjectの生成や削除は基本的にはデータアクセス層の役目。
DIコンテナはサービスやデータベースアクセスといったロジック的に独立したコンポーネントを取得するためのもの！

---

AOPとトランザクション管理
SpringではAOPの機能を使用してPOJOにトランザクションの機能を追加することでEJBと同等の宣言的なトランザクションを実現することができる。

---

データアクセス層
JDBCを直接扱うことは面倒＆永続化ロジックを複雑にしてしまう

SpringはJDBCを抽象化するためのフレームワークを提供している。
SpringJDBC抽象化フレームワークはSQL文を利用するタイプのDBアクセスフレームワークでR/Oマッピングに向いている。

利用方法
「SELECT文」と「SELECT結果とエンティティクラスとのマッピング」を記述するだけでよい。

→SQLを使い慣れている開発者や参照系が主体となるWebアプリケーションでR/Oマッピングを行うにはSpringJDBC抽象化フレームワークの利用のほうがお勧め。

---

SpringORMインテグレーション機能

SpringJDBC抽象化フレームワークを必ず使う必要はない
SpringのO/Rマッピングインテグレーション機能を利用すればHibernateやiBATISが簡単に利用できる
このインテグレーション機能を利用した場合、それぞれのフレームワークをじかに利用するよりも簡単になる。

---

今まで見てきたようにSpring上ではWebコンテナなどに影響されないPOJOベースのアプリケーションが作られる。
POJOベースであるということはJUnitなどを利用したユニットテストが容易に可能だということ。

インターフェースの実態は定義ファイルで管理しているので実装に影響を与えることなく利用するコンポーネントをMockオブジェクトに変更することができる。