MVCってどうなのよ？

雑文 SE

先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。

Life is beautiful: Ruby on Railsの「えせMVC」の弊害

Ruby on Railsの「えせMVC」の弊害という記事が話題になっているので、個人的に思うところを書きます。

まず、論点を整理すると。。。

  • RailsではO/Rマッパーである ActiveRecord を使用した抽象化したデータベースをモデルと呼んでいる。
  • Railsの解説書などではモデルにビジネスロジックがかかれずにコントローラにビジネスロジックがかかれているケースが多い（みたいだ）。
  • それは MVC の一番大事な部分である、「データの整合性」をモデルが保証することが守られておらず MVC とは呼べない「えせMVC」である。

ということかと思います。

んで、Web上で多い反論としては以下の2点のようです。

個人的には、上記のような反論は元記事の主張とちょっとかみ合っていないような気がします。

どういう事かというと、元記事の主張は、PofEAAでいうところの「ドメインモデル＋データマッパー」を使った設計を目指しているように思えるのですが、その設計方針の妥当性についての議論があまりされていないような気がするからです。

「ドメインモデル＋データマッパー」を使った設計というのは、データと処理を同じ場所に置いて関心を集約することと、実装の詳細は隠蔽し代わりに外部契約を守るようなAPI設計をすることだと思います。

これらは、オブジェクト指向の基本的な考え方で、注意深く設計されたAPIを使っている限り、どんな使い方をしてもデータの整合性は守られるという元記事の発想の元になっているところだと思います。

一方、ActiveRecordのようなO/Rマッパーを使用したデータベースのテーブルとオブジェクトが1対1に対応しているモデルというのは、実装の詳細であるテーブル設計を全然隠蔽していないので、例えばテーブル設計の変更といった実装上の変更を利用者のコードを変えずに対応することができません。

ActiveRecordを使用したオブジェクトの上にもう一層ビジネスロジックを実装する層を用意して、コントローラからActiveRecordのオブジェクトを直接扱わないというのであれば別ですが、そうでなければActiveRecordのオブジェクトにビジネスロジックを実装したからと言って、元記事で主張しているようなデータの整合性を100％保証する注意深く設計されたモデルにはならないのではないでしょうか。

じゃあ、やっぱり元記事の主張のようにRailsはえせMVCでダメなフレームワークなのかというと、個人的にはそうは思っていません。

問題なのは、ドメインモデルを注意深く設計することが本当に効率的なシステム開発につながるかどうかということです。

正直言って、ドメインモデルを注意深く設計することで得られる利益より、それにかかるコストの方がはるかに大きいのではないかと思っています。

仮にドメインモデルを注意深く設計してデータの整合性を保証するようなモデルを作れたとしても、稼働後に起こるいろいろな変更要求に対応しようとすると、ドメインモデルの根底から見直さなければならなくなったり、最初の設計者と運用メンテナンスを行う人が違う人となってしまって場当たり的な修正ばかりが入ってしまって、ドメインモデルが破綻してしまうことが実際の現場では多いように思います。

MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避けよう」というオブジェクト指向の発想がある。

Life is beautiful: Ruby on Railsの「えせMVC」の弊害

そもそも、この元記事にあるオブジェクト指向の発想そのものに「どうなのよ？」と疑問符を投げかけたいところです。

オブジェクト指向の考え方は文字列やリスト、ハッシュマップなどの、プログラム上のシステムよりな構成要素の抽象化には非常に有用で、現代的なプログラミングではオブジェクト指向で設計されたライブラリなしにプログラムを組むということはほぼ考えられないと言っていいと思います。

そういったシステムよりな構成要素を抽象化したオブジェクトは確かに、公開されたAPIが内部のデータの整合性を100％保証するということを守っています。

しかし、同じようなオブジェクト指向の抽象化をビジネス領域の概念に派生させてモデル分析をして、将来にわたってメンテナンスしやすいモデルを設計することは、非常に困難だと考えた方がよいのではないかと思います。

そんなことをするくらいだったら、単純なデータベースの抽象化をモデルとして、可読性の高くてテストのしやすいコードを維持管理していく方が絶対コストパフォーマンスがいいだろうと思うわけです。ようはビジネスロジックはオブジェクト指向に多少反していても、手続き的なコードでいいじゃないか、と。

PofEAAでいうところの「トランザクションスクリプト＋アクティブレコード」を使用するということになると思います。

そういった、オブジェクト指向の考え方をビジネスドメインに適応すること自体がどうなのよ？結局うまくいっている例ってすごく少なくない？っていう話がもっと出てくればいいな、と思っています。