[seasar-s2dao-dev:301] Re: [Seasar-user:7923] [S2Dao] 名前変換規約におけるアンダースコアの扱い

[Hirotaka HONMA]

本間です。

on Mon, 25 Jun 2007 14:04:21 +0900
in [seasar-s2dao-dev:300] Re: [Seasar-user:7923] [S2Dao] 名前変換規約におけるアンダースコアの扱い
SETO Azusa <[E-MAIL ADDRESS DELETED]> wrote:

> (1) テーブル名の大文字小文字を区別する場合にユーザ側の
> カスタマイズによって対応可能にしたい
> (2)変換方法をコンポーネントとして登録することによって、
> Employee(クラス名) → TBL_EMPLOYEE(テーブル名)のような変換にもカスタマイズ
> で対応可能になる
> 
> といった狙いがあり、BeanMetaDataCustomizerを設けました。
> 単に変換する/しないの2択ならDaoNamingConventionの
> プロパティでもいいのでしょうが、そうでもないので。

同意見です。(2)は大きいですよね。

> > XxxxCustomizerという名前から
> > org.seasar.framework.container.ComponentCustomizerを連想した
> > のですが、処理内容がNamingConventionに近かったので気になった
> > のです。
> 
> S2のComponentCustomizerのことを考えるとBeanMetaDataCustomizer
> という名前は変えてもいいのかもしれませんが、(TableNameStrategy?)
> 変換方法をDaoNamingConventionのプロパティでなくdao.diconに
> 登録するコンポーネントで決めるという方法自体はそのままでいいと
> 思うのですが、どうでしょう？

そうですね、結局カスタマイズ方法が3パターン以上出てきそうで
すから個別のコンポーネントへ分けておく方が良さそうですね。

クラス名は...TableNamingとか?

(想定するカスタマイズパターンがそう多くなく、案件ごとに個別
となるケースが多いのでしたら、DaoNamingConventionを案件固有
のものに変更してもらう、という利用形態かなと思うのですけれど。)

> >> (1)DatabaseMetaDataを見る場所を増やしたくない
> >
> > これの理由をお聞きして良いでしょうか?
> 
> のほうですが、これはあちらこちらでDatabaseMetaDataの取得が
> 遅いといわれているので、パフォーマンス上ボトルネックになり得る
> 場所を増やしたくないというという理由です。もっともDatabaseMetaDataが
> どれくらい遅いかプロファイリングしたわけではないので定量的な
> 根拠があるわけではないですが...

りょうかいです、MetaDataを見なくても、動作して && プログラミ
ングを簡潔にできるのでしたら、その方が良さそうに思います。