Hatena::ブログ(Diary)

newta(にゅーた)の日記 このページをアンテナに追加 RSSフィード

2011-01-17

[][]ORマッパーならDomaが一番。

すっかり明けてますね。

まあ、夏くらいから更新してないですが。。

ともかく、今年もよろしくお願いします。


で、Domaなんですけど、

実践投入すごくしてます。いっぱい使ってます。感謝。

今のところ、ORマッパーを使うならDomaが一番の選択肢です。

  • 理由
印象はS2Daoのようで、
S2Daoよりサポートしている部分でかゆいところに手が届いてる感じ。

selectは外だしSQLのみにすることで実行されるSQLが分かりやすく
定義箇所がsqlテンプレートファイルのみなので管理しやすい。

SQLテンプレートSQLコメント内に設定構文を書くので
SQLをそのまま実行して試すことが出来る。

aptによるチェックで、sqlテンプレートと条件やvalueの定義に
間違いがある場合、すぐに分かる。これとっても重要。
S2Dao使ってたら実行しないと分からない事がすぐ分かる。
条件のプロパティの定義忘れとかスペル間違いとか、何回やったことか。。
S2Daoなら1個のsql修正で5回以上実行することになったかも。

EntityクラスのプロパティEnumやユーザ指定のクラスに直接設定。
Domainクラスを用意することで想定外の値が来たときに即時エラーとなる。
想定外の値が他のロジックを回って、バグ調査に掛かる時間を
格段に下げてくれていると思う。

DomaToolでjavasqlsqljavaのソース移動が楽チン。
これ半端なく必要です。sql探すことはめったに無いです。
あと、sql文直してるときにパラメータ追加するので
javaにも返ってこれるのでとってもいい!

あとは、今回はS2使ってますが、S2非依存なので
SpringのプロジェクトやDIコンテナを使えないプロジェクトでも使えます!
DIコンテナなしのプロジェクトでも使って行きたいです。

忘れてることがあるかもしれないけど、いいこといっぱい。

SQL書けるちゃんとしたメンバーなら

外だしSQLのほうがチューニングとか出来るし、

他のSQLツールも使えるし、直感的だと思う。


Seasarプロダクトは標準でS2JDBCがあるので印象を書くと、
S2JDBCは自動生成と外だしSQL両方使える。
update,insert,deleteはjavaで書いても分かる。

でも、selectとなると、結構難しいのを書くことが多いので
難しいSQLの生成をjavaのほうで書くと分かりにくくなってしまうことがある。
なので外出しにするのだけど、そこで外出しにするルールがないと、
このクエリjavaにあるのかsqlファイルなのか、管理箇所が2つになるので
ルール設定が重要だと思う。
自分はめんどいのですべて外だしのDomaは分かりやすくていいと思う。


あとソースで組み立て系は、SQL単体でテストできない。
実行してみないとどんなSQLになるか分からないから。
S2DaoDomaのいいとこだけど、
SQLコメントに構文を書くのでちょっと凝ったやつでなければ
SQLファイルのやつをそのままSQLとして実行できるからいいよね。
iBatisとか惜しい感じ。Domaのほうが一歩先を行ってると思う。


S2JDBCを使うならjavaで書くか、外だしSQLにするかのルール決めを
しっかりするか、
ルール決めなくても見通せるくらいのプロジェクトサイズのときには
ガンガン作れるかも。

難しいクエリが多いときは結局外だしSQLで管理することになるのでDomaが自分的にはおススメ。


  • 悪いかも
全然思いつかないけど、ひねり出すと、
Daoの方の動作をカスタマイズしたいときにaptのほうを修正しないといけない。
経験ある人が少なそうなので調査・学習面とかが大変かも。
まあ、よほどのことしなければ直すこと無いですし、デメリットなのか微妙だけど。
それより要望を出すとガンガン機能追加してくれますので、全然問題にならないですけど。


Listenerクラスの使いどころがいまいち分からない。
共通クラスを定義して、各Listenerクラスに継承させたりしてみたけど、
S2を使っているせいだけど、事前、事後に処理をしたい場合、AOPで実行できるので
あんまり意味無いな、、、って思った。

個別に処理させたい場合はDaoメソッド呼ぶ前に普通にロジックの中で処理するし、、、。

標準で設定したい値があったらテーブルのほうでデフォルト値の設定しちゃうし。。

updateがentityごとの共通で何かありそうな予感がするけど、
今のところ無いので、どこで使ったらいいか難しい。。

自動生成でテーブルから一応全部作ったけど削除しようかなと思ってます。
DIコンテナがあって、AOP使えるなら適宜必要なやつだけ作ったほうがいいかも。
Doma-GenのuseListener=falseで実行。

  • 今日思いついたこと
DomainアノテーションfactoryMethodが追加されて喜んだ。
あんまり無いかもしれないけどInterfaceにDomainアノテーションをつけて
factoryClassを指定できればInterfaceなDomainオブジェクトが出来るかも。
ほんとにあんまり使わないだろうけど。。
enumclassで共通のinterfaceを一瞬持たせようとしたけど
登場人物が多くなるのでやめたときに思いました。。

Doma最高。あんまり書いてる人いない印象だけど。。

すごくいいので使ってみてください。

今、普通のプロジェクトで使うORマッパなら自分の中ではDoma一択ですよ。

taediumtaedium 2011/01/17 22:27 Listenerクラスは、テーブルに共通のタイムスタンプとか更新ユーザーIDとかをアプリで設定する場合を想定しています。

カスタマイズが難しいのはたしかにそうですね。お奨めとしては、カスタマイズを考えるよりはDomaのデフォルトの仕組みで難しい要件については@Delegateで逃げるが一番いいかも。もちろん機能追加など要望してくれれば検討します。

newtanewta 2011/01/18 00:14 コメントありがとうございます。
要望も色々聞いていただいてDomaすごく使ってます。

Listenerクラスはやっぱり共通のタイムスタンプやユーザですよね。。
共通のものはCommonEntityのクラスを用意して
そちらに定義して使っているので、AOPで普通に処理出来そうなんですよね。

DIやAOPなしでシンプルに使いたいときと@OriginalStatesには使えそうな感じがしてます。。

いまはListener使って更新してますけどねー。


Domaはデフォルトで十分かゆいところまでサポートされてると感じてますよ。
悪いところはほんとにあえて言うと、といった感じで。。

また何かあればお願いします。

トラックバック - http://d.hatena.ne.jp/newta/20110117/1295268594