Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。Hibernate)から多くの(激しい)返信が寄せられて書かれたのが問題のエントリです。アンチパターンとは何かの定義として下記の2つを挙げています。当初は有益だが、長期的にみると良い結果以上の悪い結果を招く。確証があり繰り返されている別の解決方法がある。当初は良さそうに見えたORMがいざ使ってみると問題が明らかになり、しかもその時には切り替えるわけにもいかなくなるというのが彼の主張です。彼による皮肉がたっぷりの論説の最後に付いていたまとめリストは下記のとおり。ORMはSQLベースのモデルよりも最初のうちはシンプルで理解しやすく、手早く書く事ができる。効率はどんなプロジェクトでも最初の頃は十分。不幸にもそれらのアドバンテージはプロジェクトが大きく複雑になると消失し、抽象化は破綻し、開発者はSQLを使わなければならなくなる。ORMの抽象化はほぼ100%のプロジェクトで破綻する。オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。不適切にクエリをオブジェクトにマッピングすることによって、ORMを廃止しない限り簡単には修正できない非効率性がアプリケーションのあちこちにばらまかれるリレーションを保存する代わりにORMを全てに適用する場合、設計をよく考える必要がある。データが元々オブジェクトならば、NoSQLにオブジェクトを記録する方がリレーショナルデータベースよりも早い。データが元々リレーショナルならリレーショナルデータベースに対するオーバーヘッドになるだけ。リレーショナルなクエリはモデルレイヤーに隠蔽する。APIの設計は汎用化の誘惑に打ち勝ってアプリケーションに必要なデータを返すようにする。オブジェクト指向設計はリレーショナルなデータを効率的に表現できない。これはORMが解決できないオブジェクト指向デザインの根本的な制限だ。ORMを使った事がある人にとっては心当たりがありまくりな主張ではないでしょうか。意外と長文なんですが原文を読んでもらう方がORMが良さそうにみえて問題が起こり、そしてその解決方法などのより正確な主張がわかります。元の記事には現時点で47のコメントが付いており盛り上がっています。長所を併存させる新しいもの作らなきゃね。偏るからよくねぇんだ。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。us@alistersjpで更新をお知らせしています。(15秒)オクトキャットのフィギュアがついに発売開始。使用に同意したとみなされます。ポリシー%d人のブロガーが「いいね」をつけました。