A-Listers

サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。

ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない

このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。

• 当初は有益だが、長期的にみると良い結果以上の悪い結果を招く。
• 確証があり繰り返されている別の解決方法がある。

当初は良さそうに見えたORMがいざ使ってみると問題が明らかになり、しかもその時には切り替えるわけにもいかなくなるというのが彼の主張です。彼による皮肉がたっぷりの論説の最後に付いていたまとめリストは下記のとおり。

• ORMはSQLベースのモデルよりも最初のうちはシンプルで理解しやすく、手早く書く事ができる。
• 効率はどんなプロジェクトでも最初の頃は十分。
• 不幸にもそれらのアドバンテージはプロジェクトが大きく複雑になると消失し、抽象化は破綻し、開発者はSQLを使わなければならなくなる。
• ORMの抽象化はほぼ100％のプロジェクトで破綻する。
• オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。
• 不適切にクエリをオブジェクトにマッピングすることによって、ORMを廃止しない限り簡単には修正できない非効率性がアプリケーションのあちこちにばらまかれる
• リレーションを保存する代わりにORMを全てに適用する場合、設計をよく考える必要がある。
• データが元々オブジェクトならば、NoSQLにオブジェクトを記録する方がリレーショナルデータベースよりも早い。
• データが元々リレーショナルならリレーショナルデータベースに対するオーバーヘッドになるだけ。
• リレーショナルなクエリはモデルレイヤーに隠蔽する。ただしAPIの設計は汎用化の誘惑に打ち勝ってアプリケーションに必要なデータを返すようにする。
• オブジェクト指向設計はリレーショナルなデータを効率的に表現できない。これはORMが解決できないオブジェクト指向デザインの根本的な制限だ。

ORMを使った事がある人にとっては心当たりがありまくりな主張ではないでしょうか。意外と長文なんですが原文を読んでもらう方がORMが良さそうにみえて問題が起こり、そしてその解決方法などのより正確な主張がわかります。また元の記事には現時点で47のコメントが付いており盛り上がっています。
さて、みなさんはORMを次のプロジェクトでも使いますか？

via:http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

関連:
データベースの間違った使い方10項目 « A-Listers
いきあたりばったりのアーキテクチャと教訓 － Publickey

シアトルに住む高校生の少年が自身の企業をActivePerlなどで知られるActiveStateに売却したそうです。話題になっているのはDaniil Kulchenkoさんで彼が起業したのはPerlのPaaSサービスであるPhenonaです。なお買収額は未公表のようです。彼はパートタイムでActiveStateに加わる予定らしく今後要注目のハッカーかもしれませんね。先日のDuoStackの買収もありましたがPaaSに関しては提供できるスタックの種類を揃えるべく早くも統廃合が始まっていますね。

これからPaaSを使うかどうかを考えている我々はどれだけこの少年に遅れをとっているのでしょうか･･･

via:http://www.geekwire.com/2011/seattle-area-15yearold-sells-startup-company-activestate