O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
2009.10.12
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。
その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。
・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題）
↓
・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない）
↓
・O/Rマッピングにより抽象化したデータは一見れっきとしたModelに見える（ここが誤解のもと）
↓
・O/RマッピングとHTMLテンプレートを使っただけで、自分は「MVCのデザインパターンに従った設計が出来る」という幻想を抱かせる（これが大きな誤解）。
↓
・本来ならModelの中に記述すべきビジネスロジック（ビジネスルールに基づいてデータベースにアクセスし、データの整合性に責任を持つロジック）をControllerの中に記述しはじめてしまい、結果的にController層が必要以上に分厚くメンテナンスしにくいアプリケーションができてしまう（スパゲッティのできあがり）。
ちなみに、私は「O/Rマッピングが悪い」とも「O/Rマッピングを使うな」とも言っているわけではないので勘違いしないでいただきたい。単に「この業界でプロとして仕事をするなら、使う言語やフレームワークにかかわらず、オブジェクト指向とMVCのコンセプトだけはしっかりと理解した上で仕事をしてほしい。そして、O/Rマッピングを使う時には、それだけでModel作りが終わったと誤解してはいけない」と言っているだけである。
オブジェクト指向と同じく、MVCのコンセプトは「はやりすたり」とは関係のない良いアプリケーションを設計する上での基本中の基本。Ruby on RailsやJ2EEを使ったウェブアプリケーションにも、Cocoa/UIKitの上のiPhoneアプリケーションにも通じる話だということを覚えておいてほしい。
読者の皆さんからいただいた情報によれば、この問題は２００３年の時点ですでに指摘されているようだ（Anemic Domain Model）。Rails上で犯しやすい設計上のミスに関しては「Skinny Cotroller, Fat Model」というエントリーが参考になるので一読をお進めする。
MVCこそがAnemic Domain Modelを助長しているという意見もあり、あまりMVCを良しとした前提の議論は危ないと感じます。
http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html
Posted by: hiro | 2009.10.12 at 15:37
前記事には「誤解されたから」と追記をして、さらにこの記事ではRailsだけ名指ししたことについて認識不足を認めておられるのですから、”釣り”を示唆するのは無用な反感を招くだけだと思いますよ。
敢えてRailsを名指しするのなら、前記事コメント欄でYuguiさんが言及されているactive recordパターンの限界、つまりActiveRecord::Baseのサブクラスにビジネスロジックを実装する場合の限界といった、もう一段階踏み込んだ議論を聞いてみたかったです。参考URLとして挙げられた「Active Record vs Objects」も主題はそちらのはずです。
Posted by: tkyk | 2009.10.12 at 18:28
同感です。
アーキテクチャーや手法などの知識をヒケらかしてばかりで
中身を見てないので、ソースを荒らされてから解るんだと思います。
「MVC」「ORM」など、はたまた「アジャイル」（←まったく的を得ていない用語。。）
をベラベラと並べ、イザ実装になると新人や経歴が分からない中国人などに丸投げ。
納品されてから、スパゲッティだと解り、それを直させる為にまた他社へ丸投げ。
この頃エンジニアも空洞化が進んでいるので、納品されたソースはほとんどこれの類です。
私が思うに、いまどきはカスタマイズやデバッグ、運用などを見越して設計、実装をしていないのでは無いでしょうか。
工数を少なくして利益を得ようとしているようで、スクリプト言語でササッと作って、
バグやカスタマイズが入ると、それを覆うように他者が実装していく。
ツギハギだらけのソースになっていく。
どちらが正しいとは言えませんが、PerlやPHPなどをデバッグすると、
結構溜息が出ます。。精神的につらい場合も。
今はJavaは仕事で見てませんが、皆さんのコメントを見てると同様なのかなぁと。
Posted by: MY | 2009.10.12 at 23:33
satoshiさん、ブログ、いつも楽しく拝読しています。
＞MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題）
これは、問題ではないと考えます。
経験が浅く不勉強な人でもアプリケーションができる、というのはそれ自体画期的ですらあります。こう書くと、出来のわるいエンジニアを責めるように聞こえるかもしれませんが、この「人」というのが、本職のエンジニアではなく、エンドユーザーだったりするかもしれません。
また、深い知識がなくてもそれなりのアプリケーションを組むことができるようになるのは、フレームワーク利用のメリットの１つです。
むしろ問題は、「えせＭＶＣ」（データの整合性がとれないような設計）を許してしまうフレームワークそのものかもしれません。
でも、Ruby on Rails にその責任を全て負わせるのは酷な話にも思えます。すると、問題は、エバンジェリストと呼ばれるような人たち、あるいはメディアの提灯記事やベンダーの宣伝かもしれません。簡単な在庫管理アプリケーション（実態はＤＢへの単純なＣＲＵＤ）をRailsの例などとして生産性向上を実感させる、というような、よくある記事です。
そして、それを経験が浅い人が鵜呑みにして、サンプルの単純なCRUDアプリケーションを改造して、えせＭＶＣが出来上がる。。
「エバンジェリスト」という呼称自体、批判精神が欠如していることを自認しているようで、そんな人の言うことに価値を置くことが、そもそもおかしいことではありますが、フレームワーク利用の情報源の多くがその周辺にあることもまた、この問題の根の深さなのかもしれません。
結論としては、今回のsatoshiさんのような批評が少ないことが問題です。
ということで、これからのエントリにも期待しています。
Posted by: こむ | 2009.10.14 at 08:35