@DBFlute, Java, Doma まだ全然完成ではありませんし、いつ完成するかは未定です。 「Doma + DBFlute」のExampleです。 dbflute-doma-example DBFluteは他のO/Rマッパとも一部機能で連携できるようになっています。 (他にもS2JDBCとの連携やHibernateとの連携のExampleがあります)
# # その機能とは： # o ReplaceSchema o SchemaHTML (Docタスク) ReplaceSchemaは、一度使うと手放せない機能です。 実際に、O/RマッパはS2JDBCで、DB環境の構築とテストデータの管理は、 ReplaceSchemaを利用しているプロジェクトを幾つか聞いています。 レガシーシステムに、ReplaceSchemaだけを新たに適用した例もあります。 SchemaHTMLは、Docタスクで自動生成されるテーブル定義一覧のHTMLです。 説明よりもSchemaHTMLをとりあえず見てみるのが一番： dbflute-doma-exampleのSchemaHTML テーブル数が多ければ多いほど関連(FK)を辿れるリンクが役に立ちます。 OutsideSqlTestも、利用可能ですが、同様の機能は本家から出てくると 思うので(もうあるのかな？)、これはあまり意味はないかも。 また、EntityやDaoの自動生成には全く手を出していません。 Domainクラスの扱いなどを考えると、ささっと実装ってわけにはいかないのと、 いずれ本家からちゃんとした自動生成ツールが出てくるかと思うので。
# # 環境の細かい話： # テストは「PKによる検索」だけです(いずれ増えるかも!?)。 (Domaの使い方のためのExampleではないので) DIコンテナは「Guice」を使っていますが、この程度のExampleであれば、 Domaの仕組み的にはDIコンテナは要らなかったかも。 (まあ、もうやっちゃったからいいや...) トランザクションは「Atomikos」を利用しています。 データベースは「H2」を組み込みとして利用しているので、 DB環境の準備・起動は不要です。 すぐにReplaceSchemaやOutsideSqlTestなどお試し実行が可能です。 (H2Dialectが無かったので、とりあえずStandardDialect使ってます) 「lib/forExecute」配下のライブラリは、テスト環境のためだけの利用で、 Domaの実行には無関係です。DomaはJDKのLoggerを使っているようなので(!?)、 CommonsLoggingやLog4jも本当は要らないかな。テストだけで使ってます。 (JDKのLoggerを使ったことがないので環境作れず...) littleAdjustmentMap.dfpropにて、 「isSuppressParameterCommentCheck = true」 と指定しています。 OutsideSqlTestでのパラメータコメントのチェックを抑制しています。 パラメータコメントの仕様がDBFluteと違うためです。
# # Domaについて： # とにもかくにもフレームワークのメインポリシーとして、 「わかりやすいエラーメッセージを出力する」 というのを挙げている点がとても高く評価したいところです。 DBFluteのユーザであれば、既に分かっているかと思いますが、 DBFluteも同じポリシーを持っています。 (まだまだ道半ばで、もっともっと改善していく予定ですが...) というか、DBFluteを世の中に公開する前から、というか、 ひたすら機能を実装するディベロッパーだった時代から、 フレームワークのこのポイントを重視していました。 独自に作成するフレームワークでも、できる限りこのポイントを 考慮して実装したものでした。 およそ三年前にDBFluteを世に出し、様々な場所でこのポイントを 主張し続けてきましたが、大雑把に以下のような反応が感じられました。 技術技術なアーキテクト ： 否定はしないけど「ふーん」という感じ 現場寄りなアーキテクト・ディベロッパー ： もう大歓迎 周りのフレームワークを見ても、このポイントを重視しているものは、 少なくとも二、三年前にはあまりなかったように思えます。 (無論、前面に出してなくてもちゃんとしているフレームワークもあります) また、フレームワーク開発する上で、このポイントはとても実装が大変な ところなのですね。フレームワークの中で 「綺麗にモジュール分けして実装すればするほど」 実は大変になってきます。その内部モジュールとしては正しい例外でも、 それはディベロッパーにとってはうれしくない例外だったりします。 また、ディベロッパーにとってうれしい情報がその内部モジュールの 処理には不要で、例外メッセージに含めづらいこともあります。 内部レイヤの境目でcatchして新たな例外にする、ってのも結構手間ですし、 どんどんネスト例外が増えていくのでそれはそれで見づらい例外に。 例外の原因が二つ三つ状況によって変わってくるというのもフレームワーク 開発者を悩ませる要素の一つです(メッセージに気を遣わないと)。 (DBFluteは割り切って、処理には不要でも例外メッセージのためだけに 内部モジュールに引数で情報を渡してたりします。綺麗ではないですが 低コストで実現できる方法なので...) Domaのポリシーは、もちろんDBFluteが影響ではなく、自然の流れだと 思いますが、それでも、このポイントを広めていきたいものとして、 このDomaのポリシーはうれしいし、苦労もわかるので応援したいものです。 Domaでこのポイントが評価されれば、その後DBFluteを知ってもらったときに、 逆にDBFluteも評価されやすくなるわけですしね。
