Spring入門

Java・J2EE・オープンソース Spring入門 ~より良いWebアプリケーションの設計と実装

Java・J2EE・オープンソース Spring入門 ~より良いWebアプリケーションの設計と実装

積読したままだったのだけど、やっと読んだ。

第1章 Webアプリケーション概論

2006年頃に、あるシステムのアーキテクチャフレームワークを設計する上で、この章を何度も読み返した記憶がある。結局Springは使わなかったのでそのまま積読状態になってしまったが、この章だけでも買った価値があると思っていた。

第2章 Springの導入

セットアップ
Spring IDE

SpringIDE-Sampleプロジェクトの作成手順が書いてないので補ってみた。

  • Javaプロジェクトとして作成。srcとbinは分離する設定。
  • ソースはダウンロードしたファイルをコピー。
  • ライブラリはspring-framework-1.1の中から必要なものをコピー。
Springの導入

インポートとあるが、実際は自分で「Spring-1.1」Javaプロジェクトを作って、「spring-framework-1.1」の中身を全てコピーして作る。そして、全ライブラリをクラスパスに追加するとコンパイルできる。

以下補足。

  • JDK1.6だとjava.sql.Wrapperがjavax.sql.DataSourceに追加されていてコンパイルエラーのクラスがあった。そのため、JDK1.4.2_05を入れた。下位互換はあるとはいえ、こういうケースもあるのね。
  • PreparedStatementでも一部コンパイルエラーになっていた。廃止されたメソッドがあるようだ。
  • spring-mock.jarのソースは含まれていない。

第3章 DIコンテナ

感想など
  • サンプル少なっ。しかも構築手順も自分で妄想して補う必要あり。
  • BeanFactoryとApplicationContextの違いは、ApplicationContextがBeanFactoryを拡張したもの。実際、インタフェースレベルで継承関係が存在する。よって、BeanFactoryを利用することはないのでは?最初からApplicationContextの紹介だけでよい気がする。
  • いまいちわかり辛いので、ネットで調べてみたが、ネットの情報も分かりにくいものばかり。みんな、Springを広めたいと思っていないのか?Seasar見た後だと余計に不親切に見える。
その他の情報
  • 付属のリファレンスは英語だが一番充実しているかも。

第4章 アスペクト指向プログラミング――AOPAspect Oriented Programming)

Introduction
  • AOPの対象となるオブジェクトに任意のインタフェースを追加し合成させる機能。
  • ProxyFactoryを利用する。
  • 通常はProxyを利用するが、これにはインタフェースが必要になる。しかし、ValueObjectにインタフェースは過剰なため、CG-LIBによって動的にインタフェースを抽出する機能もある。これを利用することでインタフェースを作成しなくともProxyを利用できる。
DIコンテナの利用
  • DIコンテナを利用することで、AOP関連のソースを設定ファイル側に移動することが出来、ソースをすっきりさせることができる。
  • ただし、設定ファイルは複雑になるし、タイプセーフでもないのでトレードオフか?この流れを受けてアノテーションの利用が活発になったのかな?

第5章 DBアクセスとトランザクション管理

DAOの作成
サンプルの実行
java -cp ../lib/hsqldb.jar org.hsqldb.Server -database mydb 
    • DatabaseManagerの起動
java -cp ../lib/hsqldb.jar org.hsqldb.util.DatabaseManager
    • binにmydbのデータファイル等が出来る。
  • demoのrunServer.batとrunManager.batの方が楽に出来てよいかも。
  • 停止はDatabaseManagerからshutdownコマンドを発行すればよかったはず。Ctrl+Cでもいいけどね。
フレームワーク
感想など
  • DIとAOPによって宣言的トランザクションを実現していることが分かる。
  • サンプルもClient-Service-DAOと全レイヤーをカバーしているので分かりやすい。
  • 今までの話がやっとつながる。ここまで読んでやっと価値が出る。

第6章 MVCフレームワーク

感想など
  • コンポーネントやレイヤーの境界が明確化されているのはよいかな。ただし、実際問題として個々のレイヤーの利用技術を変更することってあるのだろうか?この柔軟性を実現するため、クラス数も増えるしわかり難くなっている気がする。
  • リソース層については利用技術を変更する可能性はあるかも。OracleからDB2とか。SalesForceメタデータを利用することでリソース層の抽象化に成功しているし、.NETのEntityFrameworkも概念モデルを利用することで抽象化している。なのでデータアクセス層のレイヤは明確化したほうがよいかも。
  • プレゼンとビジネス層という観点では、Webサービスとかバッチでビジネス層を再利用することを考えると分離しておいた方が無難かな。
  • 以上からレイヤー分けは重要だけど、利用技術を交換可能にすることはそこまで重要ではない気がする。まぁ、人によって使いたいものがことなるので広くサポートするに越したことはないだろうが、トレードオフとして複雑で巨大なものになってしまう。単一のフレームワークで全て交換可能にするのではなく、Seasarのようにレイヤー毎にフレームワークを用意して結合する方が複雑さを減らすことが出来るのだろうか。結局フルスタックで考えると似たようなものになるので、プロジェクトのテンプレートを生成するようなツール(Eclipseプラグイン)を提供する方が重要なのかな。
  • 単純な遷移や検索/更新処理、Formの処理といった単位でControllerが提供されている。場合分けが規定されていて標準化しやすくてよいかも。慣れれば使いやすそう。

第7章 Strutsとの連携

感想など
  • 選択肢はDelegatingAcitonProxyとActionSupport。ActionSupportは従来のJDNIと似てるので、こっちが普及したと思われる。
  • DelegatingAcitonProxyを利用した場合、Actionはリクエスト単位に生成されるのかな?生成されないとビジネス層にフィールドを持てず、使いずらいからなぁ。リクエストごとにActionのインスタンスを生成するのは良いことだと思う。もう、そういうレベルのメモリとかCPUのコストを気にする時代ではない。むしろマルチスレッドにおける潜在バグが減ってよい。

第8章 Hibernateとの連携

感想など
  • SpringのDIを利用することでHibernateのSessionを隠蔽し、ビジネス層とデータアクセス層を疎結合にできる。
  • Hibernate特有の機能を意識する必要がある。
  • キー重複はDBとHibernateのキャッシュの2種類になるため、両方で同じように例外処理を出来るようにする必要がある。
  • キャッシュを使うため、実際にDMLを発行するのはSessionのcommit時になり、例外処理をService内に記述できない。よって、flushによって明示的にDMLをDBに対して発行させる必要がある。
  • Hibernateそのものの知識がないとちょっと分からない点もある。

第9章 iBATISとの連携

感想など
  • JDBC抽象フレームワークと比べてO/Rマッピングを共通化したり、SQLの共通化がしやすい。
  • また、SQLを外だしすることが出来る。
  • iBATISは1.3系と2系でインタフェースが異なるため、Spring側でもそれぞれに対応したAPIを用意している。
  • 1.3系と2系のjarファイルを一緒にしておくとエラーになるため、利用するバージョンのjarファイルのみ置くこと。

まとめ

読み辛い部分はあったけれど、良書。3章(DIコンテナ)と4章(AOP)をもう少し手厚くしておけば、Amazonのレビューが割れずに済んだのかも。5章まで読めれば3章と4章の話もつながるし、サンプルも分かりやすいので、ここまで我慢できるかどうかが分かれ目な気がする。