Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2008-01-30

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つ目の自動生成は、開発者が自由にデータベースの定義をできるプロジェクト向けです。どっちも必要なんじゃないかと思っています。

habuakihirohabuakihiro 2008/01/30 16:05 ちょっと待て(^^;

これがあればこれがあれば 2008/02/01 00:13 javaのフレームワークでスキーマ管理は世界初ではないですか(私が知らないだけ?)

TomatoTomato 2008/02/01 11:30 「抽象クラスを継承してエンティティ特有のビジネスロジックを実装する」ってことは、そのエンティティは貧血でないドメインオブジェクトってことでしょうか。
SAStrutsの機能リファレンスでは「複数のアクションから共通に使われるような機能は、サービスクラスで実装すると良いでしょう」との記述もありますが、サービスとエンティティに実装するロジックの切り分けは、やはり粒度に応じてってことになるのでしょうか。
これについては、どのようにお考えですか?

TomatoTomato 2008/02/01 11:53 あ、そもそもエンティティにDIは行われなかったですね。JdbcManager等をエンティティの中で使用するようなロジックは微妙ですね。
このあたりが今のDIコンテナ全般のネックなんでしょうか。ファウラーたんにもお話伺いたいところです。

戯 2008/02/01 21:07 もしかしてActiveObjectsのも似てますか?>スキーマ管理

Connection: close