« SharpReader使ってます | トップページ | Aspectセミナー感想 »

2004/09/16

ORマッピングに最適解はない

 下記のORマッピングの議論を読んで改めて、ORマッピングがシステム開発のボトルネックであり、ORマッピングにBestな解はないことを確認した。
#かのファウラー氏も悩んでいる(「ドメインロジックとSQL」)のだから、当然かも。

●ドメインロジックとSQL
●ポストRDB(前編)
●ポストRDB(後編)
●データベース系アプリケーションで、データや処理をどこまでクラス化する?
●Entity Bean批判

 ORマッピングの実装方法は、下記の3パターンに分類できると思う。しかし、どれも致命的弱点があるように見受けられる。

【1】JDBCを使う
【2】EJBを使う
【3】ORマッピング用フレームワーク(Torque、Hibernate等)を使う

 それぞれの弱点は下記のように感じる。

【1】ソースにSQL文を埋め込んでしまうため、うまくレイヤー化しないとスパゲティコードになる。しかも、トランザクション制御や排他制御のロジックをアプリケーション側できちんと作りこまねばならない。

【2】EJBサーバーを起動する必要があるので、ただでさえ重い。よく言われる「永続化は欲しいが分散機能は不要」という議論は確かに一理あり。
 実際の開発で使うEJBは、CMPとStateless SessionBeanしか見たことがないが、それだけでも作るのに労力がかかりすぎる。

【3】TorqueにしてもHibernateにしても、SQLをJavaで書けるようにしただけ。余計にロジックを解読しにくくなる。レスポンスもあまりよくない。

 多分、RDBを使う時点で、オブジェクト指向の技術が解決に向かないのではないか?
 ORマッピングは、オブジェクト指向の最大の弱点だと思う。

|

« SharpReader使ってます | トップページ | Aspectセミナー感想 »

日記・コラム・つぶやき」カテゴリの記事

プログラミング」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック


この記事へのトラックバック一覧です: ORマッピングに最適解はない:

« SharpReader使ってます | トップページ | Aspectセミナー感想 »