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マッピングは、オブジェクト指向の最大の弱点だと思う。
| 固定リンク
「日記・コラム・つぶやき」カテゴリの記事
- 考えながら書く人のためのScrivener入門の感想(2020.12.06)
- 課題は問題点をひっくり返す表現だけで良い場合もある(2020.09.28)
- ツールを使いこなせる事の重要性が増している(2020.05.28)
- ココログHTTPS化のメモ(2019.12.26)
- 「小水力発電が地域を救う」の感想(2018.04.06)
「プログラミング」カテゴリの記事
- Ruby技術者認定試験の感想(2020.05.08)
- 前処理大全の良いところ~SQLとRとPythonで対比できる(2019.07.10)
- WinSCPでトンネリングする方法のリンク(2018.09.09)
- 仕様書にもExcel脱却が求められている(2017.12.23)
- ソフトウェアの複雑性は本質的な性質であって偶有的なものではない(2017.05.05)
コメント