久々に開発をやっていた(やっている)ということもあって、ほぼWebWorkのみで、SpringのJDBC系のライブラリのみ使用するという構成にしてみた。SpringのJDBCインテグレーションは、Templateメソッドで行けてない部分もあるので、そこは一つクラスを作って、Wrapして煩雑というかソースコードが汚くなる部分を吸収させた。WebWorkは元々Strutsとは違ってベースとなる設定さえ書いてしまえば、その後の設定はあまり必要なく割と lightに使えるので、それを最大限に出してみた。ちなみにアノテーションで画面遷移を定義しなかったのは、案件の事情で同一のアクションを複数定義して画面遷移先を変更する要求が出そうだった事。(予想通り出て来たんだけど)
結果として、DIコンテナと組み合わせたレイヤーアーキテクチャのアプリケーションの場合と比較して出て来たメリットは、
- Tomcatの起動が速い、動作中(リクエスト)も速い
- 比較的コードが追いやすい。レイヤー化してインターフェースを切ると Ctrl + クリックで一発で飛べないし...
- トランザクション境界がアクションの実行メソッドに集約される。
もちろんそれほど難しいロジックを書いていないから出て来たメリットとも言える。逆にデメリットは
- テストが少し大変。WebWorkのActionはServlet APIへの依存度が少ないもののHTTPヘッダーにアクセスする箇所などは部分的に困る
- ぶっちゃけ、Service Locatorということになるので、必要なコンポーネントを自分で取ってこないといけない。
- クラスを分割するとしんどい。例えば、アクションクラスの中でロジックの実装クラスを分けたいとかなった時は、上のService Locatorの問題との絡みで自分で使うコンポーネントを設定してあげないと行けないので面倒。
0か1で rollbackかcommitするようなアプリケーションでは向いている実装方法だけど、条件により更新したりしなかったり、セーブポイントを使いたかったりすると、たぶん宣言的トランザクションが使いたくて仕方が無くなると思う。実際に今回は使いたいと思った箇所が2カ所ほど出て来ていた。
2年くらい前にやっていたWebWork2とSpringをがっちりインテグレーションした構成よりも、マスタメンテ画面ではこれくらいの構成のほうが作りやすい。今回はテスト用の入力画面をDTOから生成するコードジェネレータを作ったので更にスムーズに作れた。でも、少し外れるロジックが出てくると苦しい。そこが今のところの課題かなぁ。一部、テストコードのスタブ的な物は生成できると良いのかもしれない。少し考えてみよう。
あとSpring 2.0から追加された SimpleJdbcTemplateとNamedParameterJdbcTemplateは意外に悪くない。ただ上にも書いた通りTemplateメソッドなのでコードが汚くなる。そこを解決してしまえば割とシンプルに作れる。
最近のコメント