[jpa:37] Re: JPA は単独で使ってもあんまり便利じゃない

[Yasuo Higa]

ひがです。

> 小林 (koichik) です．
> 
> Date:    Wed, 25 Apr 2007 01:45:29 +0900
> From:    naoki kishida <[E-MAIL ADDRESS DELETED]>
> To:      [E-MAIL ADDRESS DELETED]
> Subject: [jpa:32] Re: JPAは単独で使ってもあんまり便利じゃない
> 
> > もちろん、今のJPAがベストだとは思いませんけど、DB←→POJOというのは重要
> > じゃないかと思います。
> 
> そこは外せないでしょうね．
> ただし，View と組み合わせることを前提に考えたとき，
> その POJO が「テーブル」と対応付けられた
> 「エンティティ」クラスであることの是非とか，
> 永続コンテキストの必要性とかには議論の余地ありかな，と．
> 
POJOがテーブルとほぼ一対一に結びついていることが
重要だと思います。

なぜなら、スキーマ(テーブル)からPOJOを自動生成したり、
スキーマからスキーマを更新することが簡単にできるように
なるからです。

なので、ドメインモデルとしてRDBMSとは無関係にモデルを
つくり、そこからがんばってテーブルとマッピングするのは、
はやらないんじゃないかと思っています。

JPAの製作者の意図はそうではないみたいですが。

テーブルの第三正規化みたいに、ある程度機械的に
モデル化できることが重要。

テーブルの正規かもうるさい人間はいろいろいうでしょうが、
うるさくいうと誰でも運用できるわけではなくなるので、
結局使われなくなってしまう。

ベストでなく、誰でもほどほどできるくらいが
普及するのではないかと思います。

JPAもいろいろややこしい機能はありますが、
そんなのは割り切って使わないようにして
シンプルな機能に絞って使えば、標準化されている分
悪くないのかなと思います。

で、JPAのどこがとっつきにくくしているかというと、
永続的な状態とメモリ上の状態が自動的に更新される機能だと
思っています。

ある意味、永続コンテキストですね。

ODBのような機能を持ち込もうとしているんですけど、
中途半端なんですよね。
削除は自動的に行えないし。

エンティティのライフサイクルの難しさも永続コンテキストに
起因していると思います。

ライフサイクルなし(ある意味ずっとデタッチされた状態)で
検索、更新、できればそれでいいんじゃないのと思います。
更新は、EntityManager#insert(),update(),delete()を
呼ぶようなのり。

エンティティのマッピング
(ざっくりいうとEntityに記述するアノテーション)はJPAの
標準にあわせ、永続コンテキストを含むEntityManagerのAPIは
もちこまず、S2Daoののりで呼び出せるようにするのが、
Next S2Daoです。

テーブルとエンティティを自動生成するようなツールは、
既存のものをそのまま利用でき(マッピングはJPAと同じだから)、
JPAの複雑さは取り除いたようなフレームワークです。

SQLも8割自動生成。残りの2割は今のS2Daoと同じで
SQLファイルを書いてResultSetをBeanのプロパティに
マッピングする方式。
> 
> > > そんなわけで (どんなわけで？)，今後 Seasar で
> > > 提唱していくアーキテクチャでは，従来サービス層とか
> > > ロジック層とか呼ばれていたレイヤはなくなることに
> > > なりそう．
> > > そこで推奨の DB アクセスフレームワークは，当然 (？)
> > > JPA (Kuina-Dao) ではなく，S2Dao やその新しい
> > > バージョンになりそうです．
> > 
> > 考え方はSeamに近いですかね？
> 
Seasar2の次のアーキテクチャでは、テーブルから
Entityを自動生成し、HTMLからPageクラスを自動生成し、
EntityとPageの変換は、Dxoを使い、ビジネスロジックは、
Pageに記述することになります。

単純なのが一番の特徴。自動生成しやすいアーキテクチャなのも重要。

Seamは便利なところもいろいろありますが、複雑ですからねー。
Ruby to Java本で、Struts, Spring, Hibernateは非本質的な複雑性が
高いのが問題だといわれていたのと同じ問題のような気がします。

--
Yasuo Higa
[E-MAIL ADDRESS DELETED]