Webアプリケーションをなめるな後日談

今日は、ITpro EXPOで高橋会長とパネルディスカッションがあったのですが、Matzが遊びに来ていたので、Webアプリケーションをなめるなの真相を聞いてみました。聞いたといっても実際に聞いたのは、高橋さんです。俺のほうからはききづらいよね(笑)。記憶が完璧でないので、正確な話ではないですが、大体はあってるはず。
Matzは、言語オタクなので、Rubyをはじめプログラム言語の悪いところは指摘せざるを得ないそうです。もちろん、良いところも。
だから、PHPを貶める意思もないし、Rubyを持ち上げる意思もない。オタクとして問題があるところは指摘せざるを得ない。
大体はそういう感じです。私は、ヲタではないので、その辺の気持ちが良くわからないのですが、羽生さんのアニヲタ振りを見るとそうなのかもしれないですね。
私も最初あのエントリを見たときは、ちょっと違和感あったけど、話を聞いて気持ちはわかりました。あることについて真剣すぎるんですね。だから、適当に流すことができない。

S2JDBCの自動生成

S2JDBCの自動生成サポートは、2つ考えています。1つは、データベースの情報から、Entityを作る機能。これは、おもにDBAがいる開発現場向きの機能です。
作るEntityは、GenerationGapパターンで作ります。例えば、従業員用のEntityの場合、AbstractEmployeeにカラムに関するマッピング情報を実装します。
Employeeクラスは、AbstractEmployeeクラスを継承し、関連の情報と、そのEntity特有のビジネスロジックを実装するようにします。
最初は、EmployeeとAbstractEmployeeの両方のクラスを作成しますが、テーブルの定義が変更された場合は、AbstractEmployeeだけが更新されます。
DBAのいる開発現場向きと書きましたが、すでにスキーマが定義されている場合の初期のEntityを定義する場合も使えるでしょう。
2つ目は、Entityからスキーマ定義を更新する機能。Railsのマイグレーションとは違います。Javaの場合、Railsみたいに差分情報を書いていくのではなく、Entityの定義そのものを直接書き換えたほうが、Javaっぽいきがします。
そして、マイグレーションする場合、最初に既存データをExcelに保存し、全てのテーブルを削除します。Entityの定義に従って外部キー以外の定義を作成して、Excelのデータをインポートします。最後に、外部キーを全て張りなおします。
データベースのバージョンは、マイグレーションの中で管理するのではなくて、Subversionなどで管理するイメージ。Entityの定義は、Entityを利用するほかのクラスと密接に結びついているんだから、Javaのクラスと同様にバージョン管理するのが自然だと思っています。
2つ目の自動生成は、開発者が自由にデータベースの定義をできるプロジェクト向けです。どっちも必要なんじゃないかと思っています。