既存のStrutsプロジェクトへS2DAOを適用してみる

Seasar2を使ったプロジェクトを経験した。
全体としては開発ツールとしての完成度も考えると
.NETの「型指定されたDataSet」には遠く及ばないが
データベースに関しての操作は非常に楽であった。
また、動的にSQLを組み立てるのはSQLコメントの
使い方さえ覚えてしまえば簡単。

経験したプロジェクトはSeasar2の良さを
あますところなく殺す、独自のフレームワークを
作られていてほとんど意味が無かった上に
プロジェクトそのものの進め方がでたらめ
だったので超大失敗プロジェクトだったが。

さて、以前Strutsを用いたシステムがあるのでこれに
S2DAOだけを適用してみる。
SAStrutsは使用しない。
struts-configファイルが不要になるなどのメリットは大きいが
そんな機能は利用しないので。

基本的にJavaのフレームワークは
・jarファイルをコピーして入れる
・設定ファイルを書く
この程度で済むはずなのでそれほど構える必要はない。


Seasar2は component(要するにクラス) として定義されたものを管理対象とする
のが基本である。
Seasar2が管理対象とするクラスはアプリケーションの中のどれなのか、
を定義ファイルで指定する必要がある。
※SMARTデプロイという自動 component 登録機能を利用するなら設定ファイルは不要。

■まず環境(Environment)
１．S2DAOは s2-dao-1.0.51.zip をダウンロード
２．また、定義ファイルの差し替え機能を利用したいのでSeasar2.4もダウンロード。
※なぜかS2DAOのダウンロードには2.3しか含まれていない。

・S2DAOのlibフォルダにあるファイルを全てWEB-INF/libへコピー
・Seasar2.4のlibフォルダにあるファイルを全てWEB-INF/libへコピー
同じ名前でバージョン違いのファイルは、古い方を削除
(例えばlog4j-1.2.8.jar log4j-1.2.13.jarなら1.2.8を消す)
・S2DAO、Seasar2.4のresourcesフォルダにあるdiconファイル、
log4jファイルを元プロジェクトのs2resources(新たに作成する)にコピー
・s2resourcesフォルダの中身をクラスパスに含めるように、
ビルドパスの設定でソースフォルダとする

「libのjarファイル(hsqldb.jar以外)とsrcのj2ee.dicon(Seasar2.4の場合はjdbc.dicon)を CLASSPATHにとおせば、S2Daoを実行できます。」
と書いてあるのでこれでよいはず。

■dao.dicon は定義ファイルの差し替えで変更する
設定を変更する必要がある。なぜならSQLファイルの文字コードがデフォルトではJISAutoDetectだからだ。
元々のStrutsプロジェクトはワークスペースのデフォルトをUTF-8にしている。
１．dao.diconはs2daoのjarから内容をコピーして cust-s2dao.dicon として s2resourcesにコピー
jarファイルは単なるZIPファイルなので拡張子を変えればすぐに抜き出せる。

<component class="org.seasar.dao.impl.DaoMetaDataFactoryImpl">

<property name="sqlFileEncoding">"utf-8"</property>

</component>

設定は上記のようにした。

２．さらに定義ファイルを差し替えるために、s2container.diconを作成。
実際はEclipseのChuraプラグインで生成されたファイルをコピーして来た。

<component class="org.seasar.framework.container.factory.SimplePathResolver">

<initmethod name="addRealPath">

<arg>"dao.dicon"</arg>

<arg>"cust-s2dao.dicon"</arg>

</initmethod>

</component>

上記内容を<components>タグの間に追加。

■Oracleへの接続設定
Seasat2.4ならj2ee.diconではなくjdbc.diconらしいので、
中身を見てみると既にサンプルがコメントとして入っていた。
H2をコメントアウトしてOracleのコメントを外し、サーバー、ユーザ等をセット

■JavaBean
Emp_Mst用のJavaBeanを作成する。

１．publicフィールドに対応しているハズなので、アクセサは不要。
カラム数分のフィールドを宣言すればよい。
「ECODE」というカラムなら ecode という名前のフィールドにすれば良い。
データタイプとのマッピングはドキュメントを参照した。
２．Tableアノテーションで実際のテーブル名を指定

■S2DAO用のコードを記述(Implementation)
■Dao
NameAsYouLikeDao
の命名規則に従ってEmpMstDaoを作成。

１．使用するJavaBeanをS2Daoアノテーションで指定
２．社員番号とパスワードだけを指定する、getEmpメソッドを宣言。
３．SQLをメソッドにアノテーションで指定
４．パラメータ用の変数 [メソッド名+ "_ARGS"] getEmp_ARGSフィールドを宣言

■Seasar2で利用するコンポーネント定義用のdiconファイル
components.diconを新規作成し、作成したEmpMstDaoインターフェースを設定
これはDAOインターフェースの数だけ登録が必要なようだ。

SMARTデプロイの規約に従っていれば設定ファイルは不要だが、
既存のアプリケーションに適用する場合はパッケージ構造を
簡単には変更できない事も多いので、これで良いと思われる。

×Seasar2のWEBアプリ設定はしてはならない
app.diconとS2Servletの指定をしてしまうと、
リクエストがそちらに乗っ取られてしまうのか、Strutsが動作しなくなる。

S2DAOやSeasar2.4を解凍したフォルダには
exampleのプロジェクトがあるので
Eclipseにインポートしてしまえば
動作させるためのコードがすぐに参照できる。

■動作させる(Run)

１．S2Containerを初期化
２．DAOコンポーネント(インスタンス)を取得
３．DAOメソッドの呼び出し
４．S2Containerの破棄

これだけで良い。

S2Container s2 = S2ContainerFactory.create("components.dicon");
s2.init();
try {
     EmpMstDao dao = (EmpMstDao) s2.getComponent(EmpMstDao.class);
     model.beans.EmpMst emp = dao.getEmp(userID, password);
} finally {
     s2.destroy();
}
このような感じ。
これだけでDBへ接続して、SQLアノテーションで指定した
SQLが実行され、オブジェクトにマッピングされ、
自動的に接続が閉じられる。
接続はデフォルトでコネクションプールが使われている。
(Tomcat等のコネクションプール設定は不要)

■SQLを別ファイルに

public String getEmp_ARGS = "ecode, password";
@Sql("select・・・・")
public EmpMst getEmp(int ecode, String password);

となっていたのを変更してみる。

public String getEmp_ARGS = "ecode, password";
@SqlFile
public EmpMst getEmp(int ecode, String password);

として、SQLを「EmpMstDao_getEmp.sql」というファイルに
移動してDAOと同じパッケージに置くだけ。

■SQLを自動生成
SQLのWhere条件やOrderByをQueryアノテーションで指定すれば
自動的にSQLを生成してくれる。

public String getEmp_ARGS = "ecode, password";
@Query("WHERE ecode=/*ecode*/ and password=/*password*/ ORDER BY name")
public EmpMst getEmp(int ecode, String password);

SQLファイルそのものが不要になる。
デフォルトのメソッド命名規則で、insert や update に対応するメソッド名があるが
それ以外のメソッド名にすれば、検索として扱われる。
戻り値が使用するBeanおよびそのリスト、配列であればよい。


■問題点(Problems)
このプロジェクトではすでに POIライブラリを利用しており、
その機能が動作しなくなったので、Seasar2.4に含まれていた
POIライブラリは削除して、元々利用していた jar ファイルに戻した。

若干とまどった部分はあったが、あっさりと適用できた。
全てのプロジェクトがそうだとは思わないが、
jarファイルのバージョンによる不整合がPOIライブラリしか出なかったので、
問題は少なかったように思う。

■終わりに(Finale)
ITプロジェクトは時間が全てコストに跳ね返る。
Seasar2を適用したい、以前のプロジェクトがStrutsを利用していた、
さあ、SAStrutsだ、と短絡的に考えない事も重要。
特に今回のようにS2DAOを利用して得するのはプログラマーだけ。
ユーザーにはほとんどメリットが無い。
多少保守性があがるといったメリットはあるかもしれないが
現時点では分からない。
こんなコストを請求してはならない。

指示待ち人間

そういう気持ちが湧き上がる事も多々ある。

「私は指示待ち人間ですから言われた事しかできません」

勘違いしてはならない。

指示待ち人間は言われた事すら出来ない。

考えるのをやめてしまったから。

言われた事が理解できない。

でも指示待ち人間になりたい時がある。
対症療法しかできなくなった人が上の立場に居た時は。

.NETでの致命的な画面描画のちらつきを誤魔化す方法

.NETは
ちょっとコンポーネントの数が増えると、
画面ロードとかのタイミングで、劇的に描画がちらつきます。
私はあまり気にならないのですが、どうしても何とかして欲しいとの要望があり
以下の対応をしました。

こういう宣言をどこかにしておきます。

Private Declare Function SendMessage Lib "user32.dll" _
Alias "SendMessageA" _
(ByVal hwnd As Int32, _
ByVal wMsg As Int32, _
ByVal wParam As Int32, _
ByVal lParam As Int32) As Int32

Private Const WM_SETREDRAW As UInt32 = 11

実際に使用する箇所での前後処理
SendMessage(Me.Handle, WM_SETREDRAW, 0, 0)
　　　実際の処理
SendMessage(Me.Handle, WM_SETREDRAW, 1, 0)
これで処理中の描画を抑制できます。

というか、設計段階で何とかならなかったのかマイクロソフト！

WPFではこんなことする必要はないだろうと推測しますが、
同時にものすごく処理が遅いだろうということは容易に想像できます。
Flashにしても何にしても、アニメーションをサポートしたUIは
部品点数が多いと、使い物にならなくなる位遅くなるのが世の常。

Visual Studio2010が楽しみだ。

悪魔降臨

よくあるSE失敗ネタかと思っていたが、プロジェクトに全く必要の無い人材が
タイトなプロジェクトにやってきた。

必要なスキルはC++だった。
スキル表では相当な経歴の持ち主だったらしい。

ちなみに女性だがこの際まったく関係ない。

・仕様が読めない
・コードを書くのがとんでもなく遅い
・とにかくサンプルコードはないかと騒ぎ立てる
・自分が知らないから仕様を変えろと言う
・毎日だれかれ構わず意味の分からない質問を投げかけ、
　他の人の生産性を著しく落とす。

誰もコミュニケーションを取らなくなってしまった。
今はただのドキュメント書きだ。
その人の書いたコードは全て捨てた。
(共通クラスに共通ではない処理をたくさん
埋め込んでいた。)

おまけにその人が一番単価が高いんだそうだ。
神よ。
仏よ。

短いスパンの仕事で良かった。
しばらくは私の中のワーストエンジニアとして君臨し続けるでしょう。
その調子で様々なプロジェクトを混乱におとしいれて下さい。

コードを見ろ

そこにその人のスキルが表れている。
スキル表、職歴表、面接だけで判断してはならない。

物事を整理する力の無い人は、同じコードをコピペするのを
悪いとも思わないだろうし、複数人でのプロジェクトを
行ったことが無い人は、癖があるコードを書くかもしれない。
インデントが独特で読みにくい。
意味のないコメントだらけ。
オブジェクト指向どころか構造化すらされていない一本道のようなコード。

本人に説明してもらうと良い。
何故そうしたのかを。

そこで初めてプロジェクトに参加させるべきかどうか判断できる。
これが技術者面接だ。

技術力を見るのに技術の分からない人が面接官になるべきではない。

ストレス続き

なんとプロジェクトから撤退、という方向で落ち着いてしまった。

ど素人がプロジェクトを回している状態で、間違いなく火を噴くプロジェクトになる予定だった。
ど素人が雑誌を見て思いつきで、プロジェクト運営する。
システム構築の経験の浅いコンサルタントが、その場限りの対応をひたすら続ける。
しかもユーザーも質が悪く、かつプロジェクトに対する意欲も見られない。
EA、CRUD、DFD、ER、汎化・・・・
それよりも先に、何が必要でどうすべきかを決めるのが先だろう。
これで正解だったと思う。
サラリーマン時代は、考えられなかった事だが。
ただ、リスクをユーザーに伝えられなかったのが心残りだ。

さーて、次なるあらたなストレスに向き合いますか。

オブジェクト指向が救うのは誰か？

オブジェクト指向が本当に理解できていて、優れたデザイン(設計)が出来る人なら
まずその人が救われるかもしれない。

その人が救われるなら、その人が所属する組織もコスト削減になって
救われるかもしれない。

組織が救われるならもしかするとその周りの人たちも救われるかもしれない。

ユーザーはきっと一番最後。

でも最も救われているのはOO関連の書籍やツールを出してビジネスに結びつけている人たちだ。
間違いない。