vieweditattachhistoryswikistopchangessearchhelp

MVC、これでいいのか？

MVC への違和感、をざっくばらんに語ろうということで。--sumim

Pad＋＋より、
＞MVCそのものに対して「これでいいのか？直感に反しないのか？」と悩むことは多いです俺。

PHPより、
＞ロジックとViewを常に綺麗に切り分け可能だという考え方(=MVC！)自体、幻想なんじゃないか

を受けて。


ma2tak さんとこで、MVC だと見た目がおんなじになっちゃうのが短所（でもある）ような話を読んで、そうなのか？と思った記憶があります。--sumim

あと関心空間、Mac プログラマのバスケは、Smalltalk で言っている MVC と最近のオブジェクト指向プログラミングで言われている MVC って違うような気がするってなことを言っていましたがまだきちんと確認していません。本題とは直接関係はありませんが、もしこうした乖離があるなら面倒だなぁ…ということでメモ。--sumim

Object感覚の学びにくさの原因、Smalltalk の学びにくさの原因 とも関連あるのですが、自分としてもこの MVC は難関でした（いや。まだ突破できていないかも(^_^;)）。Apple Smalltalk から Squeak になってからも、Morphic が使えなかった（使えないと思い込んでいた）頃は、何を作るにしても MVC を使わないと「なんか駄目じゃん」的な脅迫観念があったので、それを使いこなせない状態が苦痛でした。そうそう。すっかり忘れていて今、思いだしましたが、Morphic になかなか移れなかったのは逆に MVC でないからこんなものは使えないとまで思い込んでいたフシがあります。なんなんだったんでしょうね。このプレッシャーは。--sumim

「最近は違う」については、JavaServlet勢力が話をややこしくしてる面も有るんじゃないかな。
彼らの言うMVCはMVCですらないと思う。
Servlet(彼らが言うところのController)は個々のModelObjectそのものじゃなくシステム(ページ)全体を面倒見てるだけじゃん。-戯
Tiki:JavaServerFacesくらいになればまだしも許せるけど。

＞彼らの言うMVCはMVCですらない
あ、そうなんですか。JavaScript 派の“MVC”をちょっと勉強してみます。つまるところ、JavaScript を例外として、Smalltalk の MVC と最近(?)の OOP の MVC が違うってことではないのですね。ちょっと安心。--sumim

あ。ScriptじゃなくServletですよぉ。

おお。失敬。失敬。--sumim

Servlet方面についての違和感は、以下の点について感じています。-戯

ちょっとCGIやServlet(特にStruts?)を思い浮かべて気付いたんですが、Webアプリって元々、
1つのユーザーからの要求(ボタン押しとか)に対して、
「Modelへの命令(Control)やModelの表示(View)」と、
「画面(Viewのコンテナですよね)の切り替え(遷移)」とを、
ごちゃ混ぜにして処理しちゃう、んですよね。
自分の違和感というか嫌悪感(笑)は、ここから来るんじゃないかという気がしてきました。 -戯

というわけで、Action(Struts用語：ボタンとかを押したときに処理を依頼される手続きObject)を、
MVC(Model操作)屋さんと画面遷移屋さんにキッパリ分けるほうが良いんじゃないかなと。

つまり、あるボタンは画面の内容(元をただせばModel内の情報)を更新するけど画面は切り替わらない。
別のボタンは画面を切り替えるけどModelには干渉しない。これですっきり:-D

まあ現実には、近道するためにModel操作と遷移とをいっぺんにやるボタンが欲しくなるだろけど、
そう言うときには両者の手続きObjectをカスケードすりゃいい。
で、幸か不幸かStrutsのActionは元々カスケードをサポートしてる。＃ごちゃ混ぜの問題は有るけど。

これであとは、画面のインスタンス(例：同じかたちの画面を同時に二枚出したくなったらどうする？)の問題を退治したら、
ちょっとはマシな開発環境にありつけるかな？と思ってる今日この頃。
画面の不変部分をプロトタイプとして、変化部分や更にはユーザー入力データ込みの画面をプロトタイプ継承(?)で作ったらどうかな？とかさ。

＃全ては画面遷移と歩調を合わせた関数である、という世界観は、やっぱり馴染めないみたいだ俺。
＃「うごく」のは嫌いなんですよ。運動神経鈍いしさ(藁)。まずは静物として把握したい。
＃JSPも、静的(?)な画面というものを、(左上端?から順に)出力するという"動き"でエミュレートするみたいで、どうも嫌。Velocity(テンプレートにPushするモデル)のほうが静的で好きかも。

ん？待てよ？画面の継承子孫は、いつ作ればいいんだろう？
あるView(のコンテナたる画面)に、そのSessionが最初にアクセスしたら、画面Objectは(継承で)新規作成すりゃいいだろう。
が、その画面に二度目に来訪したら、前回の画面Objectを使いまわすのがスジなのか？それともまた作るべき？

WidgetのIDってものが有る、と考えると楽かなと思ってます。
ID=画面名/画面Objectの生成番号/画面内のForm名/Form Objectの生成番号(繰り返しや使いまわしで同じFormが1つの画面に複数回出るかも知れないから)/WidgetType名/Widgetの生成番号
なんてのをURLパラメータにつけてあげて、
全ての画面/Form/Widgetをきっちり識別できる(クラスだけじゃなくインスタンス単位で)ようにしてやれば、怖いものは無いんじゃなかろうか？と。




閑話休題(?)。MVCに三権分立すれば本当に幸せになるのか？という疑問があります。

まず、善意の独裁者(笑)よろしく一体のままじゃ駄目なのか？と思うことも有ります。
見たまんまが本質そのものであるというWYSIWYGっぽい捉え方。
Delphiやってると、なんかそう思えてきました。
それにObjectを分割すればするほど、配線の数が増えちゃうんですよね(t_t)。それが厄介。
(せっかくコードがOOPで整理し易くなったのに)スパゲティ参照なんて笑い話にもならないもんなあ。

あるいは、分けるにしても、必ず固定的な3種に分けるのが常に正しいのか？と思うことも有ります。
委譲するのはしばしば良いことですが、何をどう委譲するのが良いかは状況次第で微妙に違うんじゃないかと。
で、「MVCに旨く分けられない」というケースが多いという話はよく聞きますが、
それの理由がコレなのではないか？と。他の分け方を検討したほうが良いケースだったのではないか？と--戯

MVCはデザインパターンの一つでしかないので、MVCにうまく分けられない事がある、というのは至極当たり前のような気がします。--CUE

なるほど。そりゃそうか。

でも、だとすると尚更、「常に」MVC(それがモドキかどうかはさておき)を使うことを要求するフレームワークは本当に大丈夫か？と気になっちゃう所。 -戯

まあ、「ある種の」アプリの「ある部分」に常にMVC(とか)を導入するのが適切だ、ということは有り得るだろうけど…

ところでMVCって、「デザイン」パターンなのかなあ？他のナンタラパターンだったりはしないかな？アーキテクチャパターンなんて言葉が有ったような気が…？

TikiGuion:六本松を経由して、
『MVCはOOじゃない。ていうか全てのオブジェクトにUIを用意せよ』という話題を経由して、
Allen Holubさんによる What is an object? The theory behind building object-oriented user interfacesに、
visual-proxy architecture なんていう言葉が。
これってもしかして、MVCに"匹敵"する案なんだろうか？ -戯



手っ取り早くMVCを感じ取ろうと思ったら、Oberonをちょしてみるのが一番簡単かなぁ、とか思っているんですが。--CUE

MacOberon、見つけたのですが古すぎて、PowerPC では駄目でした(^_^;)。残念。具体的にはどんなところで MVC を感じ取れるのでしょうか？ --sumim

Darwinポートがあったと思いましたが…って、私もまだ試してませんけど。そのうちDLしてみよう。なんかX-Windowが必要みたいですね。ちょっと面倒そう。
ETH-OberonシステムにはGadgetsというオブジェクト指向フレームワークがありますが、これがMVCになってます。Oberon言語の方ではありません（そりゃそうか）。
Squeak（Morph？）でするように、至極簡単にモデルとビューとコントロールをリンクできます。私がMVCに抱く感覚は、ETH-Oberonのものですね。
ただ、Smalltalkシステムほど洗練されてはいません。--CUE


MVCという言葉は

と大雑把に３つの領域を別々に指している場合が多いんだと思いました。
是非を論じるにも載っているアーキテクチャが違うんだから、分けて考えないと意味をなさないです。

あとSmalltalkのMVCについて調べていて気づいたのは、他の処理系・フレームワークがOS任せにしている部分も自前でやっているという点で、この観点を抜きにしてSmalltalkのMVCを批判はできないだろうなと思いました。--SHIMADA


このページを編集 (8162 bytes)

Congratulations! 以下の 3 ページから参照されています。

This page has been visited 23263 times.