山根です。
こんばんは。
On Tue, 17 Jun 2003 19:01:21 +0900
Takuto Wada <t-wada@....jp> wrote:
> 一般には、永続化レイヤーを構築してDBの変更が直接ダメージになることを避け
> るか、またはDBの変更に自動的に追随できるような仕組みを作る(つまりコード
> ジェネレーション)かの戦略を立てて、DBの変更に備えるというのが王道だと思
> います。
一般的にはというよりOO的にはということでしょうね。
RDBMS自体、OOからみればインピーダンスミスマッチだらけですからねf(^_^;
> Fowler氏の文章ではデータベースの定義をCVSのようなソフトウェアの管理の下
> に入れることが書いてあります。データベースはイテレーション中に何回も自動
> 的に作り直すものという位置づけです。そのためにデータベースの定義やテスト
> データの準備などをSQLのスクリプトで行い、それらをすべてCVSに入れているよ
> うです。また、DBの変更を各開発者のDBに自動的に適用するといったかなり過激
> なことも書いてあります。
後述されている通り、Torque使うとDBの定義そのものがXMLで記述可能ですので、
CVSとして履歴管理できるからＯＫですよね。
ほんと、XPer向けのフレームワークだと思います。
ＤＢに対するテストは、setupメソッドでテストデータをランダムで作成して、
tearDownで削除すると言う形でテキストデータとして履歴管理してましたが、
XUnit使えば、外だしできるのかもしれませんね。
でも、個人的にＤＢとのアクセスをxUnitで行うこと自体「unit」と言う
メタファーから逸脱してるようにも思いますけど、、、
> 私はプロジェクトで使用するかもしれないのでTorqueの評価をしているところで
> す。TorqueはどちらかというとR-Oマッピング(造語です)といった感じなのです
> が、最初からGeneration Gapパターンの適用ができるようになっていたりしてい
> るので好感度大です。
僕は、フライングして使用した口ですが、
Genration Gapパターンは、他のフレームワークと比較してとてつもなく
効果的に動いてくれいてます。
今後、Agile手法と、GenerationGapパターンは切り離せない重要な
パターンになってくるでしょうね。
> どちらにしろデータベースの規模がある程度大きくなるとコードジェネレータ等
> 何らかの自動化が必要になってくると思います。例えばJavaであれば
> DatabaseMetaData経由で実DBから定義関係を丸ごと引っこ抜いてきて自動化の具
> に使うのが面白いと思います。ただこれらのことは各種のツール(Torqueや
> Relaxer等)が既に土台を作っていると思いますので、それに便乗して色々なこと
> ができると思います。
う〜ん、、、どうでしょう。
むしろ大きくなればなるほど、性能を出すために複雑な
(intersect等サブクエリーを発行したり、ストアド作ったりView作ったり）
ストレージ構造を組む必要が出てくると思います。
＃Torqueはサブクエリー多分吐けません。
僕が未熟なだけかもしれませんが、
現在のハードウエアスペック＆コストを鑑みると、
ある規模程度以上の永続情報を必要とする場合、コードジェネレーターで
対処するのは困難でまだまだ職人の手が必要なのが現状だと
思います。
ただ、再利用の神話が崩れた現在（あれ？崩れてない？f^^;）
今後コードジェネレータなくして、
生産性を向上させることはこれ以上、困難だとも思ってもいます。
必要なのは、GenerationGapパターンを適切に用いた
コードジェネレータとコードジェネレータでサポートできない
もしくは性能が出ないケースに対するチューナーとしてのエンジニアが
必要になってくるのでしょうね。
山根 英次（Eiji Yamane)
mailto:e-yamane@....com
http://www.ne.jp/asahi/e/yamane/software/