Ruby on Railsの「えせMVC」の弊害

先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避

[tgk]

MVC以上にビジネスロジックという言葉のいいかげんさが気に入らない

[hiro360]

複数モデルを呼び出す順番もロジックなので、厳密にするとコントローラーに記述すべきじゃない、となる。どこまでやるかはケースバイケース。サービス層を知らない人のために http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?ServiceLayer

[mrkn]

こいつ Rails でモノ作ったことないんじゃないか。モデルにロジック書かないでどこに書くんだよ。アホすぎる。

[fuktommy]

HTMLを書くのがModel, Web固有の処理を書くのがController, そのほかがModelだと、最近は考えている。なかなかこう、うまいこと分割できなかったりするけど。←あ、HTMLはViewだ。

[suVene]

ここに述べられてる厳密な意味で Model 設計してるパターンって少なそう。(良いか悪いかは別)

[yugui]

これはひどいFUD。モデルなんだからそりゃ、当然ロジックを書くんだよ。controllerのaction部は5行以上書いたら負け。が、web-MVCが本来のMVCでないのは言うまでもない

[send]

MVC Model1 じゃないから MVC じゃないって読めて変な印象。Web は MVC Model2 でしょ

[lizy]

ARはレコード単位での読み書き能力を持ったオブジェクトだから、複数テーブルにまたがりうるロジックを書く場合は別の層が必要になるのは必然かも。まあ「PoEAAを読みましょう」ということですね

[ledsun]

ActiveRecordをModelと言い張る実装のRailsアプリを見てMVC厨が憤慨するいつものパターン。日本語でも2009年からあった。yuguiさんのコメントがすばらしい。

[yssk22]

例が / いや、仕入れと販売は業務として独立してないと大変かと....(欲を言えば会計はトランザクションの結果、在庫管理は棚卸しが...等) / Rails関係ない、というのはその辺からくることだが..

[clash_m45]

10年前から指摘されてるのね。

[vabo-space]

今の所MVCのベスト解説　「MVCは、モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するのを避けようという発想」「Model＝ビジネスロジックを持ち、データの整合性に絶対の責任を持つ」／Yugui氏コメが最高

[mtrock]

“素のままのActiveRecordにControllerから直接アクセスするのは避け、ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装”

[hidehara]

Ruby on RailsのMVCについての考察。M = ActiveRecordsじゃないよと意識して使おう。

[d_animal141]

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

[toenobu]

mvc

[cha-cha-ki]

うーん。コメント欄含めて、か。

[mtmt101jp]

みんなに読んでほしい

[senahate]

MVCのお勉強。

[Nyoho]

わしもブックマークしてなかった。

[muamqm]

ブックマークしてなかった

[zbih]

"ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し、ビジネスロジックがControllerに浸食していくことを意識して避けることが大切である。"

[zuborawka]

よく読まれているMVCに関するエントリ。RORのActiveRecordにもう一枚ラッピングしてようやく本来のModelになる。ビジネスロジックの整合性だけは何があっても守りぬいてこそのModel。つまりControllerを薄くせよという話でもあり

[matsumoto_r]

コメント含めて面白かった

[masutaka26]

『素のままのActiveRecordにControllerから直接アクセスするのは避け、ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し、ビジネスロジックのControllerへの浸食を意識して避ける』

[kazuph1986]

久しぶりにYuguiさんの最強コメント見て認識合わせした。

[zakinco]

古い記事だけどメモ

[todesking]

"ActiveRecordは、データベースのテーブルを単にオブジェクトの形に抽象化しただけのものであり、そこにはビジネスロジックは一切含まれていない"というのは不適切すぎる言い方では……

[takeboruta]

コメント欄が、、、おもろい

[nullpobug]

Railsに限った話ではないですね。わかりやすい説明。

[longroof]

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

[safu0826]

[Ruby on Rails]

[y_uuki]

Railsの本読んでて, Modelがやけに薄いなと思ったのは間違いではなかった

[escape_artist]

DataMapperとActiveRecordの違いがだんだん分からなくなってきてモヤモヤ。

[shiwork]

後ほどよむ。 Life is beautiful: Ruby on Railsの「えせMVC」の弊害

[northlight]

ビジネスロジックがControllerに浸食していくことを意識して避ける

[delhicurry]

ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し、ビジネスロジックがControllerに浸食していくことを意識して避けることが大切

[suginoy]

「ビジネスロジックがControllerに浸食していくことを意識して避けることが大切」

[may_2chan]

"MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するのを避けよう」というオブジェクト指向の発想がある"