アカウント名:
パスワード:
つまり、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派は全く違う
それは言わないお約束(^^)
(ただし今時HTTP依存は避けにくいでしょう。アプリを配信するためだけにHTTPとか、鯖と通信するのにHoge Over HTTPとか、色々ありますからね。JDBC Over HTTPというのも有ったような…)
元の話と同じく元祖MVC(なのか?)系のネットワークアプリの別形態として、ブラウザにクライアントアプリを送りつけるタイプがあります。FLASHやAppletもそうですし、JavaScriptでも部分的断片的じゃなくアプリ全体丸ごとJavaScriptで作っちゃう形態のものはそれに属するでしょう。GoogleWebToolkitやSproutCoreはとてもよさそうです。
しょせん
> ただ…ゲンジツのアンケンとしては何故か未だにサーバサイドWebアプリを欲しがる愉快な顧客が多いというのも事実。一般消費者向けのWebサイトならともかく。説明して理解してもらえないような客ならとっとと縁を切りましょう。よほど利率がいいならともかく、ウザい客は遠慮無く切るのがコンピューター業界の鉄則です。君が受ける地雷案件は、誰かが受けなかった地雷案件であり、君が受けなかった地雷案件は、同業他社が受ける地雷案件なのです。もし、地雷案件を避ける余裕すらないのなら、残念ながらその会社のビジネスモデル自体が終わってます。そんな会社とはとっととおさらばするのが吉ですよ。
>説明して理解してもらえないような客ならとっとと縁を切りましょう。
そう簡単にリコンできるんだったら世話ないですよorz特にこの冷え切ったご時世に。
>一般消費者向けのWebサイトならともかく。
おや?それこそ一般消費者はWeb鯖の実現方法なんて頓着しないのでは?ふつうの人は実現方法が複数あることすら想像してないように見えます。
不特定「多数」が来るサイトは工数と引き換えにメモリ消費の少なさを実現できる低レベルフレームワークのほうがいい、という意味でしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
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)
Re: (スコア:0)
それは言わないお約束(^^)
(ただし今時HTTP依存は避けにくいでしょう。アプリを配信するためだけにHTTPとか、鯖と通信するのにHoge Over HTTPとか、色々ありますからね。JDBC Over HTTPというのも有ったような…)
元の話と同じく元祖MVC(なのか?)系のネットワークアプリの別形態として、ブラウザにクライアントアプリを送りつけるタイプがあります。FLASHやAppletもそうですし、JavaScriptでも部分的断片的じゃなくアプリ全体丸ごとJavaScriptで作っちゃう形態のものはそれに属するでしょう。GoogleWebToolkitやSproutCoreはとてもよさそうです。
しょせん
Re:MVC構造のフレームワークということは (スコア:0)
> ただ…ゲンジツのアンケンとしては何故か未だにサーバサイドWebアプリを欲しがる愉快な顧客が多いというのも事実。
一般消費者向けのWebサイトならともかく。
説明して理解してもらえないような客ならとっとと縁を切りましょう。
よほど利率がいいならともかく、ウザい客は遠慮無く切るのがコンピューター業界の鉄則です。
君が受ける地雷案件は、誰かが受けなかった地雷案件であり、君が受けなかった地雷案件は、同業他社が受ける地雷案件なのです。
もし、地雷案件を避ける余裕すらないのなら、残念ながらその会社のビジネスモデル自体が終わってます。
そんな会社とはとっととおさらばするのが吉ですよ。
Re: (スコア:0)
>説明して理解してもらえないような客ならとっとと縁を切りましょう。
そう簡単にリコンできるんだったら世話ないですよorz
特にこの冷え切ったご時世に。
>一般消費者向けのWebサイトならともかく。
おや?それこそ一般消費者はWeb鯖の実現方法なんて頓着しないのでは?
ふつうの人は実現方法が複数あることすら想像してないように見えます。
不特定「多数」が来るサイトは工数と引き換えにメモリ消費の少なさを実現できる低レベルフレームワークのほうがいい、という意味でしょうか?