■
共通部品を作っている最中にまた改変。
気になることがあったので、技術的検証という名の学習時間をとってみた。
やりたいこと。
「メソッド名を渡したらそのメソッドを実行しつつ結果を返す部品を作る」
Select文を発行した後、ResultSetをなるべく触らせないようにするってのが目的。
ってか複数件検索用のロジックは「これサイコー」ってのが出来たので、
そのロジックを使いまわしたかったのだ。
もちっと詳しい話をすると、
・Selectした結果は一旦各種テーブルに応じた形で作ったEntityの配列に入れる。
・Entityの配列は取得したい件数分のみに限定できる。
→ 結果的には「Select結果 = Entityの配列要素数」ではなく
「Select結果 ≧ Entityの配列要素数」としたい。
・もちろん各種テーブルは項目数も項目名もバラバラ。
・Selectする項目数は、全項目のこともあれば1部のみのこともある
などなど。
早い話が、たとえば「1万件引っかかったけど、画面には20件ぶんしか表示しませんよ」という際に、
1万件分のEntityを作ってたら遅いので20件だけ実体化(インスタンス化)しよう。と。
こんなことをやるのです。
ってことで今回のMission。
SQLでSelectした結果が複数件になる状況限定!
各種テーブル用DBアクセス部品の高品質保証しつつ速攻開発できるか作戦〜
必要要件
(1) Entityの数は指定数のみ
(2) 指定の場所から指定数実体化する。
(3) 検索条件にひっかかった件数はまた別途必要。
(4) 指定された検索項目に応じてEntity内の編集を行う。
今までに実現したこと
・(1)〜(3)。
ただし、全項目検索のみ
ここからあと(4)を実現すべく検証するのです。
ってことで、メソッド名から実行するクラスはなんじゃろかいな?ってとこから探してみた。
あった。
java.lang.reflect.Method()
JavaDoc
使い方をみてみるとこれも必要なようだ。
java.lang.Class()
JavaDoc
調査もテストもペアプログラミングで。
いろいろ2人であれこれ四苦八苦した末、使い方を覚えた。
(´-`).。oO(いろいろめんどくせぇなこれ。)
1時間くらい格闘して使い方を覚え、
1時間くらいかけて今やりたい形でソースを書き直し、
1時間くらいかけて今までとレスポンスタイムに変わりはなさそうな実測テストを行った上で。
( ´∀`)ノ<いけそ〜や〜ん♪
っと結論をだしてみた。
とりあえず苦労の証。
以下Methodクラスを使う際のサンプルソース
// とりあえず定義
// ※ 例えばこのクラスにあるString hogehoge( String, String )ってのを実行すると思いねぇ
String strMethodName = "hogehoge";
String strData01 = "何は";
String strData02 = "ともあれ";// 実行してみる
// クラスをおこして〜
Class clsItem = Class.forName( this.getClass().getName() ); // クラスのフルパッケージです
// メソッドの引数の型を定義して〜
Class clsParam = { String.class, String.class };
// 実際に引き渡す変数名を定義して〜
Object objArgs = { strData01, strData02 };
// 実行するメソッドを確定してみる
Method method = clsItem.getMethod( strMethodName, clsParam );
// さて実行です
String strArray = (String[])method.invoke( this, objArgs ); // Castしないといけません
上記ソースはもちろん実装したDB部品のままではない。だいぶ簡略化してみた。*1
これをもちっと洗練させた上で、DB共通部品ってかDB部品にあたるClassのSuperClassに定義して。
これでDB部品Classを作るときにはSQL文とSQL文に対応したResultSet→Entityの処理を行うメソッドを作ればよいことになった。
次回から作るときにSQLの構文ミスと代入ミス以外は気にしなくてよくなった。
作戦成功っっっ!!!
オレ∩´∀`)∩万歳!!!
(´-`).。oO(ほんまかな。落とし穴まってるんちゃうやろな。どきどき。)
ってことで、これが有効活用されるかどうかはまた後日の話。
*1:サンプルとはいえ、全角空白文字を除けば一応コンパイルは通った