# Ruby on Railsは「えせMVC」じゃないよー _published: 2009/10/12_  Life is beautifulのこのエントリーは「釣り」でしょ？ - [Life is beautiful: Ruby on Railsの「えせMVC」の弊害](http://satoshi.blogs.com/life/2009/10/rails_mvc.html) > 先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 ということで、MVCの解説をされています。それは、OK。で、Railsが「えせMVC」だという理由。 > ActiveRecordそのものはとても便利なもので全く問題はないのだが、問題はRailsの解説書などでActiveRecordを使って抽象化されたデータベースをModelと読んでいるケースが多く見受けられる点だ。 > 上に述べた通り、ActiveRecordは、データベースのテーブルを単にオブジェクトの形に抽象化しただけのものであり、そこにはビジネスロジックは一切含まれていない。その意味では、MVCにおけるModelとはほど遠いものであり、これをModelと呼ぶ事は（特に初心者に）大きな誤解を生むのでとても危険である。 ここが、曖昧。上のパラグラフでは「解説書が問題」だと読めるし、下のパラグラフでは「ActiveRecordが問題」だと読めます。でも、ActiveRecordが問題ということはないと思うのです。ActiveRecordには、 `before_create` や `before_update` などのフックがあって、そこでビジネスロジックを実装することができます。また、ビジネスロジック用のメソッドを実装することもできます。 となると、解説書が問題ということになりますよね。ではなぜ、問題となる解説書ができあがるのか？それは、Railsのコンセプトの1つである「設定よりも規約 (Convention over Configuration)」が、ControllerとModelに関しては行き届いていないように見えるからです。ロジックはControllerにもModelにも書けるし、ControllerはModelをどのように呼び出すことも可能です。 「ように見える」と書いたのがポイントで。実際にはビジネスロジックはModelへ、 `before_create` や `before_update` を使うという規約に従えば、きちんとMVCアプリケーションができあがるわけです。この規約というのは、Railsの規約というより、MVCの規約ですね。ちなみに、ここで「設定よりも規約 (Convention over Configuration)」を持ち出すのは、厳密に言えば間違っているのは承知の上です。また、フレームワークによるトランザクションのサポートがどうのこうの。 とにかく、MVCに則ってアプリケーションを作ると決めたら、RailsでもきちんとMVCアプリケーションを作ることができるのです。よく、Modelはテストをしやすいから、Model（のロジック）を厚く作った方がよいという意見を聞きます。しかし、これはまったくもって本末転倒です。テストをしやすいからModelを厚くするのではなく、MVCに則って必要なビジネスロジックがModelに実装された結果、Modelが厚くなるのです。 > ここで私が強調したいのは「Ruby on Railsフレームワークは本来のMVCとはほど遠い」「Ruby on Railsの上に普通にアプリケーションを作ると、ビジネスロジックをControllerに混ぜ込んで書く事になってしまい、『データの整合性』を保つことが難しくなる」という点である。 ここで私が強調したいのは「Ruby on Railsフレームワークは間違いなく本来のMVCである」「Ruby on Railsの上に正しくアプリケーションを作ると、ビジネスロジックをModelに書くことになる」という点である。「データの整合性」については、別エントリーにした方がよさそう。