今週のあれこれ

今週は以下のような感じでした。

3/3 年休、Kijimunaのenum対応
3/4 SpringFrameworkの教育
3/5 SpringFrameworkの教育、フットサル
3/6 今度の仕事で新しく入る人の受け入れ準備
3/7 今度の仕事で新しく入る人の受け入れ
3/8 フットサル

Springの教育は、以下の本をベースに行われました。

実践SPRING FRAMEWORK

いわゆるSSH(SpringFramework, Struts, Hibernate)に触れたのですが、
扱っているバージョンが古いせいか、applicationContext.xmlやらstruts-config.xmlやら〜hbm.xml等の
設定ファイルを大量に書く必要がありました。こんなんでSSHって本当に使われているのかな。

いまならアノテーションやAutowireを駆使して設定ファイルに書く量は
削減できるんでしょうけど。

あとDIコンテナのメリットとしてよくあげられるPOJOで疎結合だからテストしやすいっていうのはまあわかるけど、
そもそもSI案件でどれだけJUnitのテストケースを書いているんだろうっていう疑問がある。

多分ほとんど書いてないんじゃないかなというのが個人的な予想。
テストケースを書くことによるメリットをフィジカルに実感していないと、やっぱ面倒くさいってなっちゃう。
（ちなみに僕はテストケース書いたことありません）
それにテストケースは繰り返し実行していかないと割に合わないけど、エンハンスが常にあるとは限らない
SI案件ではあまりテストケースを実行する機会がないだろうし。
またテストケースの保守っていうのもコストがかかる。
パッケージ開発のように自分たちでスケジュールを主体的に組むことができて、
かつ継続的にエンハンスする場合は書く価値はあると思うけど。

DIコンテナのメリットについては、以下のひがさんのエントリが参考になります。

DIのメリット - yvsu pron. yas
DIって本当に必要? - yvsu pron. yas
DIって本当に必要? その2 - yvsu pron. yas
DIって本当に必要? その3 - yvsu pron. yas
DIって本当に必要? その4 - yvsu pron. yas
DIって本当に必要? その5 - yvsu pron. yas

ひがさんも書いているようにDIはAOPと組み合わせないとうまみが無いような気がします。
個人的には宣言的トランザクションを容易に使えるのがメリットだと思います。
ログにAOPをうまく適用するのは難しいと思うし。

ただやっぱりDIって裏方の技術だと思うんですよね。

DIの上にのっかったフレームワークの魅力しだいで採用の可否が決まってくるように思います。

たとえば、
DIやAOPを導入するためにどうやって頭の固いおやじを説得するか - yvsu pron. yas
にあるようにS2DAOを使えばインタフェースだけ定義すればいいっていうならメリットは見えやすい。

SAStrutsのようにstruts-config.xmlをいじらなくてもよいっていうのもメリット。

DIコンテナ以外の例で言うと、
Strutsなら、

ServletContext servletContext = getServletContext();
RequestDispatcher requestDispatcher = servletContext.getRequestDispatcher( "/sample.jsp" );
requestDispatcher.forward( request, response );

っていうコードが無くなりますよだし、

ORマッパーをつかえば、

Class.forName("oracle.jdbc.driver.OracleDriver");
Connection conn =
DriverManager.getConnection
("jdbc:oracle:thin:@localhost:1521:ORCL", "scott", "tiger");
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery("select EMPNO, ENAME from EMP");

っていうコードが無くなりますよとなる。

やっぱ非本質的なことをやらずにすむようになってくれるとうれしいですね。