アカウント名:
パスワード:
つまり、RoRやCakePHPの.net版ということでしょうか。
リリースやライセンスはともかく実物自体はhttps://codezine.jp/article/detail/2748 [codezine.jp]「もう一つのASP.NET 「ASP.NET MVC」を知る」というCodeZineの紹介記事が昨年7月に出てるんで超「なにを今更」な気がするけど、そういう話は置いておきましょう。
「WEB MVC」とか「MVC Model2」とか言われるアーキテクチャはかなり古くから有ります。言いだしっぺはSUNあたりでしたっけか?古参のStrutsなんかがその典型的な実装(の第一世代?)と言われてます。RailsとかはStruts系のアーキテクチャを(開発の無駄が減るように)より洗練させたものです。第二か第三世代。
一方で、MVCの黒歴史とでもいうか(^^;、もともとWeb以前からMVCを自称していたGUIフレームワークの類(をやりこんでた人々:私もそうです)から見ればWeb MVCって、ずいぶんと換骨奪胎した「似非MVC」だなという印象がぬぐえない、ってのがあります。よしあしはさておき少なくとも「Javaと似てないのにマーケティング狙いでJavaScriptと命名された言語」と同様に「MVCと似てないんだけどMVCと命名されたアーキテクチャ」に思えてなりません。
WebMVCベースではなく元祖(?)MVCに近いアーキテクチャを採用したWebアプリフレームワークは最近いくつかあります。Apache Wicket(日本語書籍発売おめでとうございます! http://www.cbook24.com/shop/ProductDetail.aspx?sku=9784798022215 [cbook24.com] )とか、Click Frameworkとか、SmalltalkのSeasideとか、がそうです。ASP.NETもかなり近いアーキテクチャかと思います。
特徴を技術語でいうなら…なんだろうな、「Widget/Control/Componentの集合として成り立ってる」ことかな。Web MVCだとアーキテクチャの切れ目はMとVとC(Dto/JSP/Action)という単位といった感じですが、元祖MVCだと切れ目は「コンポーネント」というVとCがほどよく(主観)一体化した画面部品になる、という感じです。あまたのGUIフレームワークが最終的(?)に行きついた構成とほぼ同じです。
元祖MVCがどんなものか?を小難しく考えるのがイヤな人は、きわめて乱暴ですがこう理解しておいていいです:VBみたいなもの。VBはバカになりません。画面部品という単位を極限まで(開発者に)扱いやすくするとアアなるのでしょう。それが証拠にVB以外でもGUIビルダは至る所で重宝されますよね。
少なくとも個人的な(前述のようにGUIになじんだ)感想では、元祖(?)MVCの「利点」は「わかりやすいこと」です:-)。もちろん各自の経験に立脚する話でしかないですが、Web MVCだとある程度以上の規模のアプリになると「どこに何が有るんだかワケわかんね」というのが開発時の私の感想でして、正直つかれる。「ここにボタンがある」なら「ボタンに関する表示も入力も何もかも関連するコードは全部ここに固まってて欲しい」というのが(GUI派の)感想でして、そうなってないFWはガッカリ、そうなってるFWはニッコリ、なのです。
CGIあたりを発端とするのであろうWebMVCは、CGIのように「入力→出力モデル」に基づいたアーキテクチャなのだろうと思います。それ自体はいいんですが、問題は、Webアプリとは結局は(ブラウザ上で)GUIを表示するアプリであり、そのばあい「入力→出力モデル」はあまり馴染まない、という点にあると思います。パイプラインのような考え方だと「自画面への遷移」という概念をキレイに整理できない(と感じています)。
元祖MVC型のWeb FWは多くの場合「そもそも画面遷移なんてものは無い(隠蔽してある)」という捉え方をします。GUIアプリをレンダリングする先がたまたまHTMLだという捉え方です。GUIアプリに画面遷移なんて無い(少なくとも中心的概念ではなくオマケでしかない)のと同様に、元祖MVC型Webは画面遷移はオマケでしかありません。もちろんやりたければ出来ますが必須ではないということです。たとえばコード上で「なにもしなければ」同じ画面に帰ってくるのがデフォです。これはGUIアプリが「なにもしなければ」自分(のWindow)を単に表示し続けるのと同じ位置づけなんです。内部的にはHTTPやアクションが一回りしますが、「なにもしなければ」その流れはアプリコードからは完全に隠蔽されます。
デメリットはメモリを多く食いがちだという点のようです。よりリッチな画面部品(しばしば状態を抱えることも許容する)を使うので、どうしてもそうなる。
…わかりやすくて、しかしメモリを食う。これってつまり「高級化」なのだろうと私は思っています。高級言語の普及と同様に、Webフレームワークも「高級化」の道を少しずつたどるのだろうなと。
長くなりましたが、話を最初に戻します。何が言いたいかというと、
「これから斜陽になる(Web)MVCフレームワークをいまさら出すなんて、MSもヤキが回ったか?」「せっかく元祖MVC(ぶっちゃけVB)に近いASP.NETを持ってるのだから、イラネだろ?」
です。
それともMSにゃ珍しいFOSSモノで出したということが、MS的には「掛け捨て」でしかないことを暗示している、のでしょうかね…
> 「これから斜陽になる(Web)MVCフレームワークをいまさら出すなんて、MSもヤキが回ったか?」IIS7になっていまさら、URLルーティングが出来るようなったから出てきたんだよ。
> 「せっかく元祖MVC(ぶっちゃけVB)に近いASP.NETを持ってるのだから、イラネだろ?」無印ASP.NETはモバイル切り捨てられたから使い物にならないだろ。
>URLルーティング
それ自体が要らないというのが元祖MVCベースWebアプリFWの姿勢です。FWごとに微妙に温度差はありますが、一番急進的なSeasideは下記のように言っています。
http://www.ogis-ri.co.jp/otc/hiroba/technical/seaside/seaside1/index.html [ogis-ri.co.jp] >Seaside では今まで Web 系でお約束とされてきたことに反する以下のような特徴を持ちます。>URL は一過性のものを使う
一過性というか、いずれにせよいわゆる「読みやすいURL」とは真っ向反対のURLです。
最近の(別の)流行としてREST的な美しいURLを与えると言う考え方が出てきていますが、 元祖MVC派は全く違う
それは言わないお約束(^^)
(ただし今時HTTP依存は避けにくいでしょう。アプリを配信するためだけにHTTPとか、鯖と通信するのにHoge Over HTTPとか、色々ありますからね。JDBC Over HTTPというのも有ったような…)
元の話と同じく元祖MVC(なのか?)系のネットワークアプリの別形態として、ブラウザにクライアントアプリを送りつけるタイプがあります。FLASHやAppletもそうですし、JavaScriptでも部分的断片的じゃなくアプリ全体丸ごとJavaScriptで作っちゃう形態のものはそれに属するでしょう。GoogleWebToolkitやSproutCoreはとてもよさそうです。
しょせん
> ただ…ゲンジツのアンケンとしては何故か未だにサーバサイドWebアプリを欲しがる愉快な顧客が多いというのも事実。一般消費者向けのWebサイトならともかく。説明して理解してもらえないような客ならとっとと縁を切りましょう。よほど利率がいいならともかく、ウザい客は遠慮無く切るのがコンピューター業界の鉄則です。君が受ける地雷案件は、誰かが受けなかった地雷案件であり、君が受けなかった地雷案件は、同業他社が受ける地雷案件なのです。もし、地雷案件を避ける余裕すらないのなら、残念ながらその会社のビジネスモデル自体が終わってます。そんな会社とはとっととおさらばするのが吉ですよ。
>説明して理解してもらえないような客ならとっとと縁を切りましょう。
そう簡単にリコンできるんだったら世話ないですよorz特にこの冷え切ったご時世に。
>一般消費者向けのWebサイトならともかく。
おや?それこそ一般消費者はWeb鯖の実現方法なんて頓着しないのでは?ふつうの人は実現方法が複数あることすら想像してないように見えます。
不特定「多数」が来るサイトは工数と引き換えにメモリ消費の少なさを実現できる低レベルフレームワークのほうがいい、という意味でしょうか?
言いたいことは簡潔にまとめて
s/ステートレス/ステートフル/ ですか?
>「ブラウザのヒストリーを汚す」と評判が悪かった
いっそGETじゃなくPOSTにすればブラウザ(のURL欄)のヒストリは汚しませんよ。アプリ1件につき消費するヒストリも1件。むしろ画面(遷移)の数だけヒストリを汚しまくる従来型アプリよりも清潔になります。
まあそこまで気にしなくても、笑っちゃうくらいにごちゃごちゃなURLを大量にヒストリに残してくれちゃうWebアプリは既に世間に沢山転がっていますし…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
MVC構造のフレームワークということは (スコア:0)
つまり、RoRやCakePHPの.net版ということでしょうか。
Re: (スコア:0)
Re:MVC構造のフレームワークということは (スコア:0)
リリースやライセンスはともかく実物自体は
https://codezine.jp/article/detail/2748 [codezine.jp]「もう一つのASP.NET 「ASP.NET MVC」を知る」
というCodeZineの紹介記事が昨年7月に出てるんで
超「なにを今更」な気がするけど、そういう話は置いておきましょう。
「WEB MVC」とか「MVC Model2」とか言われるアーキテクチャはかなり古くから有ります。
言いだしっぺはSUNあたりでしたっけか?
古参のStrutsなんかがその典型的な実装(の第一世代?)と言われてます。
RailsとかはStruts系のアーキテクチャを(開発の無駄が減るように)より洗練させたものです。第二か第三世代。
一方で、MVCの黒歴史とでもいうか(^^;、
もともとWeb以前からMVCを自称していたGUIフレームワークの類(をやりこんでた人々:私もそうです)から見れば
Web MVCって、ずいぶんと換骨奪胎した「似非MVC」だなという印象がぬぐえない、ってのがあります。
よしあしはさておき少なくとも
「Javaと似てないのにマーケティング狙いでJavaScriptと命名された言語」と同様に
「MVCと似てないんだけどMVCと命名されたアーキテクチャ」に思えてなりません。
WebMVCベースではなく元祖(?)MVCに近いアーキテクチャを採用したWebアプリフレームワークは最近いくつかあります。
Apache Wicket
(日本語書籍発売おめでとうございます! http://www.cbook24.com/shop/ProductDetail.aspx?sku=9784798022215 [cbook24.com] )とか、
Click Frameworkとか、
SmalltalkのSeasideとか、
がそうです。
ASP.NETもかなり近いアーキテクチャかと思います。
特徴を技術語でいうなら…なんだろうな、「Widget/Control/Componentの集合として成り立ってる」ことかな。
Web MVCだとアーキテクチャの切れ目はMとVとC(Dto/JSP/Action)という単位といった感じですが、
元祖MVCだと切れ目は「コンポーネント」というVとCがほどよく(主観)一体化した画面部品になる、という感じです。
あまたのGUIフレームワークが最終的(?)に行きついた構成とほぼ同じです。
元祖MVCがどんなものか?を小難しく考えるのがイヤな人は、きわめて乱暴ですがこう理解しておいていいです:VBみたいなもの。
VBはバカになりません。画面部品という単位を極限まで(開発者に)扱いやすくするとアアなるのでしょう。それが証拠にVB以外でもGUIビルダは至る所で重宝されますよね。
少なくとも個人的な(前述のようにGUIになじんだ)感想では、
元祖(?)MVCの「利点」は「わかりやすいこと」です:-)。
もちろん各自の経験に立脚する話でしかないですが、
Web MVCだとある程度以上の規模のアプリになると
「どこに何が有るんだかワケわかんね」というのが開発時の私の感想でして、正直つかれる。
「ここにボタンがある」なら
「ボタンに関する表示も入力も何もかも関連するコードは全部ここに固まってて欲しい」
というのが(GUI派の)感想でして、
そうなってないFWはガッカリ、そうなってるFWはニッコリ、なのです。
CGIあたりを発端とするのであろうWebMVCは、CGIのように「入力→出力モデル」に基づいたアーキテクチャなのだろうと思います。
それ自体はいいんですが、問題は、Webアプリとは結局は(ブラウザ上で)GUIを表示するアプリであり、そのばあい「入力→出力モデル」はあまり馴染まない、という点にあると思います。パイプラインのような考え方だと「自画面への遷移」という概念をキレイに整理できない(と感じています)。
元祖MVC型のWeb FWは多くの場合「そもそも画面遷移なんてものは無い(隠蔽してある)」という捉え方をします。GUIアプリをレンダリングする先がたまたまHTMLだという捉え方です。GUIアプリに画面遷移なんて無い(少なくとも中心的概念ではなくオマケでしかない)のと同様に、元祖MVC型Webは画面遷移はオマケでしかありません。もちろんやりたければ出来ますが必須ではないということです。たとえばコード上で「なにもしなければ」同じ画面に帰ってくるのがデフォです。これはGUIアプリが「なにもしなければ」自分(のWindow)を単に表示し続けるのと同じ位置づけなんです。内部的にはHTTPやアクションが一回りしますが、「なにもしなければ」その流れはアプリコードからは完全に隠蔽されます。
デメリットはメモリを多く食いがちだという点のようです。よりリッチな画面部品(しばしば状態を抱えることも許容する)を使うので、どうしてもそうなる。
…わかりやすくて、しかしメモリを食う。
これってつまり「高級化」なのだろうと私は思っています。高級言語の普及と同様に、Webフレームワークも「高級化」の道を少しずつたどるのだろうなと。
長くなりましたが、話を最初に戻します。何が言いたいかというと、
「これから斜陽になる(Web)MVCフレームワークをいまさら出すなんて、MSもヤキが回ったか?」
「せっかく元祖MVC(ぶっちゃけVB)に近いASP.NETを持ってるのだから、イラネだろ?」
です。
それともMSにゃ珍しいFOSSモノで出したということが、
MS的には「掛け捨て」でしかないことを暗示している、のでしょうかね…
Re: (スコア:0)
> 「これから斜陽になる(Web)MVCフレームワークをいまさら出すなんて、MSもヤキが回ったか?」
IIS7になっていまさら、URLルーティングが出来るようなったから出てきたんだよ。
> 「せっかく元祖MVC(ぶっちゃけVB)に近いASP.NETを持ってるのだから、イラネだろ?」
無印ASP.NETはモバイル切り捨てられたから使い物にならないだろ。
Re: (スコア:0)
>URLルーティング
それ自体が要らないというのが元祖MVCベースWebアプリFWの姿勢です。
FWごとに微妙に温度差はありますが、一番急進的なSeasideは下記のように言っています。
http://www.ogis-ri.co.jp/otc/hiroba/technical/seaside/seaside1/index.html [ogis-ri.co.jp]
>Seaside では今まで Web 系でお約束とされてきたことに反する以下のような特徴を持ちます。
>URL は一過性のものを使う
一過性というか、いずれにせよいわゆる「読みやすいURL」とは真っ向反対のURLです。
最近の(別の)流行としてREST的な美しいURLを与えると言う考え方が出てきていますが、 元祖MVC派は全く違う
Re: (スコア:0)
Re: (スコア:0)
それは言わないお約束(^^)
(ただし今時HTTP依存は避けにくいでしょう。アプリを配信するためだけにHTTPとか、鯖と通信するのにHoge Over HTTPとか、色々ありますからね。JDBC Over HTTPというのも有ったような…)
元の話と同じく元祖MVC(なのか?)系のネットワークアプリの別形態として、ブラウザにクライアントアプリを送りつけるタイプがあります。FLASHやAppletもそうですし、JavaScriptでも部分的断片的じゃなくアプリ全体丸ごとJavaScriptで作っちゃう形態のものはそれに属するでしょう。GoogleWebToolkitやSproutCoreはとてもよさそうです。
しょせん
Re: (スコア:0)
> ただ…ゲンジツのアンケンとしては何故か未だにサーバサイドWebアプリを欲しがる愉快な顧客が多いというのも事実。
一般消費者向けのWebサイトならともかく。
説明して理解してもらえないような客ならとっとと縁を切りましょう。
よほど利率がいいならともかく、ウザい客は遠慮無く切るのがコンピューター業界の鉄則です。
君が受ける地雷案件は、誰かが受けなかった地雷案件であり、君が受けなかった地雷案件は、同業他社が受ける地雷案件なのです。
もし、地雷案件を避ける余裕すらないのなら、残念ながらその会社のビジネスモデル自体が終わってます。
そんな会社とはとっととおさらばするのが吉ですよ。
Re: (スコア:0)
>説明して理解してもらえないような客ならとっとと縁を切りましょう。
そう簡単にリコンできるんだったら世話ないですよorz
特にこの冷え切ったご時世に。
>一般消費者向けのWebサイトならともかく。
おや?それこそ一般消費者はWeb鯖の実現方法なんて頓着しないのでは?
ふつうの人は実現方法が複数あることすら想像してないように見えます。
不特定「多数」が来るサイトは工数と引き換えにメモリ消費の少なさを実現できる低レベルフレームワークのほうがいい、という意味でしょうか?
Re: (スコア:0)
言いたいことは簡潔にまとめて
Re: (スコア:0)
おれも昔、ステートレスにしたくてurlにずらずらごちゃごちゃ書いたこともあるんだが、「ブラウザのヒストリーを汚す」と評判が悪かった。
Re: (スコア:0)
s/ステートレス/ステートフル/ ですか?
>「ブラウザのヒストリーを汚す」と評判が悪かった
いっそGETじゃなくPOSTにすればブラウザ(のURL欄)のヒストリは汚しませんよ。
アプリ1件につき消費するヒストリも1件。
むしろ画面(遷移)の数だけヒストリを汚しまくる従来型アプリよりも清潔になります。
まあそこまで気にしなくても、
笑っちゃうくらいにごちゃごちゃなURLを大量にヒストリに残してくれちゃうWebアプリは
既に世間に沢山転がっていますし…。