Ruby on RailsのMVCは「えせMVC」だ 37
タレコミ by pidgin
pidgin 曰く、
ブログ「Life is beautiful」の記事「Ruby on Railsの「えせMVC」の弊害」が話題になっている。 RailsのMVCは厳密にはMVCではなく、Controllerにビジネスロジックを書いてしまうため、データの整合性を損なう可能性があるということだ。 これは、O/RマッパーであるActiveRecordがModelと認識されている場合があるため、 Controllerにロジックを書いてしまうのではないかと推測されている。 Railsでは、MVCをきちんと理解していないとこういった作り方になってしまうので、 フレームワークとしては不完全なのではないか、ということだ。
追記やコメントでは、「RailsではActiveRecord::Baseを継承してモデルを作り、ここにビジネスロジックを書くので、きちんとMVCになっている。 Railsの問題ではなく、使い方の問題では？」という話も出ており、 ブログの次のエントリ 「O/Rマッピング技術の進化が皮肉にも助長している『えせMVC症候群』」 では、Railsだけでなく他のフレームワークでも同じような問題があるとし、Railsだけの問題ではないということを警告している。
どっちもどっち (スコア:3, 参考になる)
制約などを全部Modelに押し込むのも間違っているし、
かといって全部Controllerに押し込むのはもっと間違っているでしょう。
invariantな制約はModelに書いたほうがいいだろうし、
入力時にチェックすべき項目はControllerに記述するべきだと思います。
判で押したように、どっちか一方だけが正しいとすると、不幸な結果になると思います。
よくあるオブジェクト指向論争と同じで、一方の極端で他方の極端を攻撃するのは無益です。
Re: (スコア:0)
そうそう。
「いろいろ」ある処理をMとCどちらに属させるかは、処理ごとに「それぞれ」決めるべき事柄。
つまり全部Mに集めたり全部Cに集めたりするのは愚か。
>入力時にチェックすべき項目はControllerに記述
いや、それすら状況によって色々振ったほうがいいと思う。
「入力時にチェックすべきinvariantな制約」とか、色々な組み合わせが有り得るわけだから。
そもそもMかCかという二者択一を迫ることが間違っている。
きっぱり分けることが常に良い結果をもたらす保証すら、無い。
分けたほうがハマリが良い場合、そうでない場合、色々あるというだけのこと。
パイプ
Re: (スコア:0)
> どんな問題もMVCというハンマーで叩きたがるお子様たちだ。
きっと、ハンマーで叩きたがる勇者の影響なんですよ。
Re: (スコア:0)
議論のポイントは似非ＭＶＣだからＭＶＣでは無い、
勘違いするなという指摘に対して
やりようが有るってのは何の答えにもなってないと思う。
パンがなければケーキを食べれば良いじゃない
と指摘するのは技術者じゃねーなって思う。
うんＭＶＣじゃないけど使えるよ、ケーキなら有るよ
と言って始めて成り立つ反論なのに
そこを言わないのは誠実さに欠けてると思う
WebのMVCをMVCと呼ぶの自体嫌だなあ (スコア:3, 参考になる)
と未だに思っているおっさんが通りますよ。まだ20代ですが。
ちなみに原典っぽいものを調べたいときは、(SmalltalkのMVCは資料探すのが一手間なので(苦笑)) ブッシュマンの「ソフトウェアアーキテクチャ—ソフトウェア開発のためのパターン体系」をお奨めします。いわゆるPoSA本というやつです。著名な汎用アーキテクチャパターンは大体載ってますので、ソフトウェアの大規模構造をざっくりとさらいたい場合は買ってもあまり損は無いかなぁと。
あとは、J2EEパターンとかPofEAAとかセキュリティパターンとか、ドメイン特化型のを業務に応じて見ていくとスムースに引き出しを増やせるのではないかと。まぁパターン全般として濫用に注意ってのは常に心しておいた方がいいですがｗ
Re: (スコア:0)
>WebのMVCをMVCと呼ぶの自体嫌だなあ
それわかる気がする。
Web系のスクリプト系言語でのMVCってなんちゃってMVCな気がする。
Re:WebのMVCをMVCと呼ぶの自体嫌だなあ (スコア:2)
MVCもHttpもCGIも理解していない設計者で状態遷移図も画面遷移図も区別付かない人は
Webの感覚でまとめて設計してくれます；；。
しかも、そのCGIをC++で書けとくる("素"の。移植性とか言われたｗ)。
営業でC++で工数稼げるのはわかるのですけどねｗ画面遷移をどうするのよ；；
自宅残業でPerlで書いたら2日でできました；
#確か、これの工数は2人月でしたｗ
閑話休題
Re: (スコア:0)
>スクリプト系言語
スクリプト系でも、出来の良い言語なら、問題なくフルセットのMVCがやれるよ。
本家のSmalltalkなんて(良い意味で)スクリプト言語だろ。
「Web」でMVCは、出来ないでもないんだが、
今流行っているRailsとかStrutsのようなCGIの延長線のシクミを剥き出しで使う奴では、
MVCは遠いね。
Zend Frameworkの場合 (スコア:2)
MVCすらモジュール扱いなZend Frameworkを使ってますが、
データのCRUDを実行するロジックは、
気が付けば自然と XxxModel.php に集まってます。
データを引っ張り出したり、更新したりする際は、
XxxModelに処理を頼み、エラー制御するだけ。
コントローラーというかアクションからは触らない。
でも新人さんに頼むと、アクションでトランザクション書いたりします。
ほとんどの処理がアクションやそのコントローラーのメソッドにあり、
結局単一のファイルで書いているのと大差ありません。
うちは今のところ、MVCを掴ませたい時は、
MとVとCと、それぞれ別の人間に割り当てて、デモのシステムを組ませてます。
喧嘩したり、似た処理がMVCのどれにもあって悩んだりしますが、
次第に分業の楽しさが分かってくるようです。
汎用的な話だよね (スコア:0)
「オブジェクト指向言語もオブジェクト指向を理解してない人が使うと・・・」
と同じ話でしょう。
Re: (スコア:0)
汎用的な話だからこそ、fool-proofのためにガチガチに自由度の少ないフレームワークがもてはやされているのでは？
だから、「あれ？Railsはそうじゃなかったの？foolには弱いの？」って話だよね。
Re: (スコア:0)
Re: (スコア:0)
たぶん読み間違えてる
Re: (スコア:0)
むしろRailsの方がガッチガチだし覚える事多いよ、触った事ないでしょ
その規約に従う事でメリットが生まれるものだもの
Re: (スコア:0)
Re: (スコア:0)
当然オブジェクト指向なんとかよりオレオレMVCが蔓延りやすくなってしまう
Re: (スコア:0)
http://www.jac-net.com/~tarzan/smalltalkers/mvc/mvc.html
このリンク先がオリジナルかどうかは知らんけど、オリジナルの著者は青木淳さんです。
Re:汎用的な話だよね (スコア:2)
かつて、リンク先以外のどこかで、リンク先とたぶん同じ文章を読んだ者です。
# 遠い昔のことなのでうろ覚え
当時、確かに感動もしたけど、余計混乱した覚えがあります。
MVCがSmalltalkの世界で「育ってきた」もので、
それ故Model, View, Controlerそれぞれの役割や定義は時代によって変遷している、
というのはよく理解できたんですが、
それからさらに時代も移り、Smalltalk以外の言語にも盛んに輸出され、
開発論も日々進化し続けている「現時点」においての、
これが真のMVCと言える「厳密」な定義ってのは結局なんなんだろう、と。
何がエセかっていうのも、まずはそっちを先に決めてからじゃないと意味ないと思う。
もちろん、SmalltalkのMVCを原典として、それ以外認めない原理主義でもいいんだけど、
その場合どうしても時代遅れな部分を内包せざるをえなくなってしまうよね。
・・・誰か決めてくれないものかな？
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
ん？でも「RDBの正規化とは何をすることか」は厳密に決められるし決まっているでしょ。
MVCは(数学的論拠が無いので)そこまで厳密にする必要はないにせよ、多少は厳密なコトバの定義があってもいいんじゃない？
定義したうえで、それを使うかどうかは各自の自由だ。
RDBだって「正規化しない自由」が有るだけのことで、「正規化じゃないものを正規化と呼ぶ」のはただの半可通だ。
Re: (スコア:0)
>開発論も日々進化し続けている「現時点」においての、
進化なんかしてねえよ。
あきらめの境地に入っただけさ。退化だな。
だからこそMVCもエセな廉価版になったし、
その他もろもろ、いずれもとてもじゃないが硬派と呼べないような「開発論」が横行する。
結局これは「クラッカーをハッカーと呼んでいいのかどうか」って問題と同じだ。
いきがったクラッカーはハッカーを自称する。
周囲の連中は面白おかしいほうに迎合して呼称を選ぶ。
結果として悪貨は良貨を駆逐する。
そういうことだ。
＃スラドでOOP談義が盛り上がらない、という時点で既にITアレゲサイトとしてはヤバイんだがね。
＃かといって「こ
Re: (スコア:0)
> いきがったクラッカーはハッカーを自称する。
> 周囲の連中は面白おかしいほうに迎合して呼称を選ぶ。
> 結果として悪貨は良貨を駆逐する。
「クラッカーはハッカーじゃない！」と騒いでいたのは半可通やワナビーだけですね。(遠藤淑子のマンガにすら出てきた！)
本物のハッカーは黙々とハックしていたよ。多分どっちでもいいやと思っていたんだろう。
Re: (スコア:0)
フリーソフトウェアはオープンソースソフトウェアではない、とかいってた人は…(ｗｗｗｗ
別にMVCが正義ってわけじゃないし (スコア:0)
答えは (スコア:0)
Grails
Re:答えは (スコア:2)
Garils [wikipedia.org]? or Holy Grail [google.co.jp]?
簡単に書ければどうでもいいんじゃね？ (スコア:0)
MVCなんて所詮素人にプログラム書かせるための方便でしかないので
どこに何があるか説明できりゃ、どこに何書いてもいいと思いますよ。
保守性？保守性に金だしてくれるならちゃんとやるけどね？
Re: (スコア:0)
"保守"にお金を出してくれないから、"保守性"を上げておくんじゃないの？
こういうのも空中戦っていうの？ (スコア:0)
テストがどうとかモデルのFatさがどうとか、という話は、元来「それがMVCかどうか」とは直交な問題です。
にも関わらず、まるでこの議論が「ほんとのMVCは何か」について語ってるかのように書いてる。
非常にきもちわるい。両者とも。
ちなみに本物のMVCについては別の人がコメントしてるね。
それは、Smalltalkとか、とにかく全然違う方角に存在しているわけで。
参考リンク (スコア:0)
(もちろん片方の意見でしかないが)これを参照しなかったら負けでしょう。
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症 [capsctrl.que.jp]
手段が目的になってね (スコア:0)
なんでもO/Rマッパーやアプリケーションフレームワークの世界で
解決しようと思ってる…もしくはそう取られかねない話題だから
無駄に話がややこしくなってるんじゃね
Re: (スコア:0)
違うと思います。別に永続化の手段としてRDBMSは使わなくても全然問題ないです。
まー、手軽だから大抵の実装ではRDMSを使っていますけど。
そうではなくてもう一段抽象レベルが上のO/Rマッパーをモデルと呼んでいいのかどうかという話です。
O/Rマッパーそれ自体はモデルではなく、もう一段抽象レベルを上げたものにしようよ派と、
別にO/Rマッパーレベルでもモデルでいいじゃん派の争いです。
他にも派閥がいますが、大別するとそんな感じになります。
Re: (スコア:0)
手軽だからっつーか、それなりの規模なら性能的にも他の選択肢ないと思うけど。
テーブル＝モデルって単位だと色々やりにくそうに見えるなぁ。
RDBMS的な都合とプログラムの都合は微妙に一致しないし、DB側に概念単位を
あわせてやる必要なないと思うが。
Re: (スコア:0)
>他の選択肢ない
その性能上の問題と、それを「MVCのMと呼ぶべき」かどうかって問題とは、全然別。
>テーブル＝モデルって単位だと色々やりにくそう
そりゃそうだ。
DBのほうが得てして「データの再利用性」をより深刻に考える必要が有るので、
より安全側、つまりより厳格に細かく分割するほうが、似合っている。
いっぽうアプリ側はアプリにとってちょうどいい粒度に落とすのが幸せ。
結局、RDBの「いくつかの」テーブルをJOINしたようなものを、1つのOOP側のオブジェクト(モデル)にするのが一番収まりがいい。
なに？JOINが(検索も更新も)面倒？
それこそそういうのをラップしてください＞ORM
「MVC」とか言って議論してるのが悪い (スコア:0)
言いたければ「MVCパターン」と言え。
「MVCパターン」なら、定義があるし共通理解もある。
MVCパターンはGoFのパターンの前からある、あるいは「デザインパターン」という概念を発想するヒントとなった、デザインパターンの大御所。誤解も無くあいまいさも無い。それ以外の意味は無い。
WebアプリケーションアーキテクチャのMVC2というのは、ModelとViewとControllerが出てくるけど、デザインパターンとしてのMVCとは明らかに違う。
Vistorという名前のついたクラスが出てくるからといってVisitorパターンと呼べないのと同様に、クラス間の役割と関係性、相互作用のステップ、目的を含めて「MVCパターン」と呼ぶのだ。
これは本来、それだけの話であって、ロジックのおき場所とか整合性保証とか、本来は別件で、議論になる必要すらもない。
時代の流れとして、あるいは慣用として、MVCといってしまうことはしょうがない、のかもしれない。言葉は生き物だから。特許も商標もあるわけではないし。ただ、それでたまに新参者の誤解を招いてフレームになったりする。
Webアプリとかのアレはとりたてて「MVC」とかとは呼ばずに（あえて呼ぶときは「MVC2」と言う）、「モデルとビューとコントローラがある」と認知するだけで良いのじゃないかね。
MVPの変形表現と言えば (スコア:0)
Taligentに組み込まれた、MVP（or passive view,supervising controller）というのもありますよ。
event駆動と相性がよいので、WebだとGWTとかASPとかで使われているようです。
http://en.wikipedia.org/wiki/Model-view-presenter [wikipedia.org]
あまり話題になってませんが、T.ReenskaugとJ.O.Coplienさんで
DCI Architectureという、MVCの後継というか柔軟な構成法を考案されてるようですよ。
http://www.artima.com/articles/dci_vision.html [artima.com]
書籍の草稿もあるようです。実際使わない場合でも、最近の開発手法を
いろいろ組み合わせているので、なにを知らないかをチェックするためにも役立ちます。