アカウント名:
パスワード:
つまり、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フレームワークをいまさら出すなんて、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派は全く違う
s/ステートレス/ステートフル/ ですか?
>「ブラウザのヒストリーを汚す」と評判が悪かった
いっそGETじゃなくPOSTにすればブラウザ(のURL欄)のヒストリは汚しませんよ。アプリ1件につき消費するヒストリも1件。むしろ画面(遷移)の数だけヒストリを汚しまくる従来型アプリよりも清潔になります。
まあそこまで気にしなくても、笑っちゃうくらいにごちゃごちゃなURLを大量にヒストリに残してくれちゃうWebアプリは既に世間に沢山転がっていますし…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
MVC構造のフレームワークということは (スコア:0)
つまり、RoRやCakePHPの.net版ということでしょうか。
Re: (スコア:0)
Re: (スコア: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の黒
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)
おれも昔、ステートレスにしたくてurlにずらずらごちゃごちゃ書いたこともあるんだが、「ブラウザのヒストリーを汚す」と評判が悪かった。
Re:MVC構造のフレームワークということは (スコア:0)
s/ステートレス/ステートフル/ ですか?
>「ブラウザのヒストリーを汚す」と評判が悪かった
いっそGETじゃなくPOSTにすればブラウザ(のURL欄)のヒストリは汚しませんよ。
アプリ1件につき消費するヒストリも1件。
むしろ画面(遷移)の数だけヒストリを汚しまくる従来型アプリよりも清潔になります。
まあそこまで気にしなくても、
笑っちゃうくらいにごちゃごちゃなURLを大量にヒストリに残してくれちゃうWebアプリは
既に世間に沢山転がっていますし…。