framework

やだおはきかいのからだになれなかった

ツッつきもらいましたが、ちょうどその前後であんどろいどの話をあーだこーだ3時間ほどしていたり。なにそのシンクロニシティ(笑で今日はやだおのあんどろいど適合度を確認していました。 まだ現時点ではアノテーションとジェネリクスに対応していないこと…

やだお

ですが、どのタイミングでオープンするかは検討中です。 ぶっちゃけ、いくらIn-Process相手で限定機能とはいえ、高速なので現段階でも用途はあるだろーなーとも思いますが、あまりSourceForge.jpに置きたくもないなー、と。だからといってSourceForge.orgな…

あるのかな?と見ていたらあったのね

PostgreSQLやMySQLはセットアップが必要なので後回しにして、ほかにセットアップが特にいらないDBで有名どころ〜と思っていたところ、そういえばSQLiteがあったなと思い、JDBCドライバあるのかしら?と見ていました。あるんですねぇ。 JDBCドライバがJNI経由…

H2にも対応してみた

HSQLDB同様、H2も差異がほとんど無いので同様に対応してみました。 こちらも前述と同様に、いわゆるIn-Processモードでテストを実行したところ、H2 1.0.69で3秒台で収束と確実に差がありますね。これもDerby,HSQLDBと同様にAS ISですが、やはり何気に差がで…

HSQLDBにも対応

現状実装した範囲だと、Derbyと変わるのはCREATE TABLEぐらいなのでHSQLDBにもサクっと対応してみました。CREATE TABLE,DROP TABLEに対応したのは、実のところ、他DBに対応するときにユニットテストが書きやすくなるというのもあるからですが。どちらもいわ…

CREATE TABLE,DROP TABLEにも対応

簡易的なものですが、entityで定義したフィールド定義とアノテーションをもとにCREATE TABLE,DROP TABLEできるようにしてみました。 キチンとテーブル設計せずにモック優先でモノを作ることもあります。TDD的にやるんですが、こういったときに簡易でもテーブ…

なんでenumを使うかというと

DELETEのポカミス修正も済んだので、整理のためにもクラス図を起こしました。 ちなみにポカミスの内容は、SELECTのWHERE条件と同じものを持ってきたことが原因で、query構築時と値セット時で意図していたものが違うというのが問題でした。 要はquery構築時は…

INSERTも対応。。。DELETEはお待ちくださいorz

INSERT/DELETEも対応完了、したんですが。 ですが、INSERTできるのにDELETEできずorz 単純にWHERE条件句の作り方に問題があるというのはわかっているので、今日のところはここまで。

UPDATEのポカミスを修正

当たり前っちゃぁ当たり前なんですが、PRIMARY KEYをUPDATEで変えようとすると怒られるDBがあります。 Derbyの場合、怒られます。ほかはどうだったかなぁ、すぐに思い当たりはしませんが。ま、普通しないオペレーションですし。なんでこれが出てきたかと言う…

UPDATEもベース完了

とはいっても未テスト。SELECTをベースにしているので、ほぼ問題はないはずだけどね。

とりあえず各種DB対応できるように対応

とはいっても、アノテーションで指定したDBに応じてハンドラを切替えるだけですが。それもFactory内で単純対応。 やりたいことを十分に簡潔に実現できているので、十二分にこれでいいんですけどね。

バインディングどうしよう

RoRのようにentityからのentityをサポートしたいわけですが、どう実現するかなぁ。 なにも考えずに実装するだけなら手はあるんだけど、ラクしたいし。とりあえずは遅延バインディングと再帰バインディングは当面サポートしないことにはしますが。面倒なので。…

enumも使いまくることにしました

5.0からC/C++でおなじみ列挙型が導入されているわけですが、Javaらしく、いわゆるタイプセーフな列挙型なわけです。 で、ちょっと面白いのが、Javaのenumは実態が定数オブジェクトなのでこんなことができます。 public enum TypeEnum { TYPE_STRING(String.c…

アノテーションを使うこととする

ドライバ/URL/ユーザ名/パスワードだけど、定数フィールドから取得するよりもアノテーションから取得した方が高速なことがわかったので、そちらを使うようにする。 どのみち5.0導入ブツを多用しているから、いまさらアノテーションが増えたところで同じこと…

とりあえず実装してみた

ひとまずDao構想その1に従って、ダイナミックプロキシの基本線を実装。 SELECTだけしかまともに動かないけど、それなりに動くものができあがり。 実際にはキチンとPreparedStatementで条件句を設定しないといけないけど、ひとまずはint値ならそのまま使える…

Dao構想その1追記

昨日のやつに書き漏らしていたけど、S2Daoと違って、 INSERT/UPDATEの切り分けはあくまで呼び出すメソッドによって決定する。 とする。 あくまで能動的に呼び出したメソッドを優先した方が分かりやすいからね。

配列とMapも限定サポートしてみた

CommonsのBeanUtilsのように、配列とMapも限定ながらサポートしてみた。 もっとも、Daoを作る分には使わないんだけどね。

Dao構想その1

ベース構想はRoRのようにできるかぎり設定を書かないで済むようにすること。将来的には構成しなおす必要があるけど、まずは動かすことを目標に、 最初のサポートDBはDerbyのみとする。テストが簡単だからね;-p javax.sql.DataSourceは当初サポートせず、java…

BeanUtilsをとりあえず実装してみた

とりあえず、基本形の配列でもMapでもない、普通のBeanを想定したものを作ってみた。 使い勝手もCommonsのBeanUtilsと変わらないから、なかなかいい感じ。もっとも、Fieldしか操作できないけどね。フフフ。

AssertUtilsをとりあえず実装してみた

とりあえず、だだっと作ってみた。使う側からは、 Assert.assertNull(IllegalArgumentException.class, "No bean specified", bean); こんな感じで使えるから楽チン。 とりあえずRuntimeExceptionだけをサポートとする。ビジネスロジック,フレームワークから…

BeanUtilsの構想その1

こいつも基本はCommonsのBeanUtils同等。 ただ、JDK5.0以降対象なので、総称型やら正規表現やらはバリバリ使うこととする。といっても、まずはField操作のみしかサポートしない。Daoから使うのもFieldのみとして楽するつもりだし。

AssertUtilsの構想その1

こいつは単純にJUnitのAssert同等。 ただしフレームワーク内で使いやすいように、例外をリフレクションを使って生成とする。いまのPCサーバ/クライアントクラスなら、リフレクションによる負荷がクリティカルに効いてくることも少ないようなので、できるかぎ…

自作フレームワークの構想その1

物件によってはライセンスやサポートの都合もあり、オープンソースのフレームワークを利用できないケースがあるので、リフレクション・ダイナミックプロキシの習熟がてら自作してみる。当初のフレームワーク構想は以下のあたりかな。まー想定はSeasarやらRoR…