アカウント名:
パスワード:
つまり、RoRやCakePHPの.net版ということでしょうか。
一応、MonoRail [castleproject.org]ってのがありましたよ。ただ、残念ながら世のWeb MVC FWのようなスマートな作りではないし、全然盛り上がらなかったようですが…
#あとはViewをもうちょっとどうにかして欲しい…
>front controller
これですね。 http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?FrontController [capsctrl.que.jp] 「複雑なWebサイトでリクエストを扱うとき、よく似たことを何度も行う必要がある。セキュリティだったり、国際化だったり、ユーザー別のビュー作成だったり。インプット コントローラの振る舞いがあちこちのオブジェクトに散らばっていたら、こういった処理は重複してしまう。それに、実行時に処理を変更するということが難しくなる。
FrontControllerでは、ハンドラーオブジェクトをひとつ使ってリクエストを送り届ることで、全てのリクエストを取り扱う。」
しかし、この議論は1つ重大なことを忘れ
リリースやライセンスはともかく実物自体は 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鯖の実現方法なんて頓着しないのでは?ふつうの人は実現方法が複数あることすら想像してないように見えます。
不特定「多数」が来るサイトは工数と引き換えにメモリ消費の少なさを実現できる低レベルフレームワークのほうがいい、という意味でしょうか?
言いたいことは簡潔にまとめて
s/ステートレス/ステートフル/ ですか?
>「ブラウザのヒストリーを汚す」と評判が悪かった
いっそGETじゃなくPOSTにすればブラウザ(のURL欄)のヒストリは汚しませんよ。アプリ1件につき消費するヒストリも1件。むしろ画面(遷移)の数だけヒストリを汚しまくる従来型アプリよりも清潔になります。
まあそこまで気にしなくても、笑っちゃうくらいにごちゃごちゃなURLを大量にヒストリに残してくれちゃうWebアプリは既に世間に沢山転がっていますし…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
MVC構造のフレームワークということは (スコア:0)
つまり、RoRやCakePHPの.net版ということでしょうか。
Re:MVC構造のフレームワークということは (スコア:1)
いわゆるfront controllerをやりやすいframeworkを出してきたってことが目新しさだと感じています。
Java文化な人々はwebやるときにstrutsをベースにやってる人が多いから、
それに近いコントロールができるものを出してきたと。
あわせてOR-mappingがしやすいEntity Frameworkも出してきてるから、
Javaな人々の取り込みが目的でしょうね。
そのあたりをMS適に.NETとして面でサポートしてくるところが、憎いというか
あざといというか、まあすごいと感じます。
さっと見たところ、ISAPI触らせるとか、HTTPHandlerを実装させるとか、
内部に手を入れなくていいのがいいところだろうな。
#おそらく、MS的には誰かが作ってくれることを期待してたんだろうけれど、
#だれも作ってくれなかったから、自分で作ったのではないかと・・・。
Re: (スコア:0)
一応、MonoRail [castleproject.org]ってのがありましたよ。
ただ、残念ながら世のWeb MVC FWのようなスマートな作りではないし、全然盛り上がらなかったようですが…
#あとはViewをもうちょっとどうにかして欲しい…
Re: (スコア:0)
>front controller
これですね。
http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?FrontController [capsctrl.que.jp]
「複雑なWebサイトでリクエストを扱うとき、よく似たことを何度も行う必要がある。セキュリティだったり、国際化だったり、ユーザー別のビュー作成だったり。インプット コントローラの振る舞いがあちこちのオブジェクトに散らばっていたら、こういった処理は重複してしまう。それに、実行時に処理を変更するということが難しくなる。
FrontControllerでは、ハンドラーオブジェクトをひとつ使ってリクエストを送り届ることで、全てのリクエストを取り扱う。
」
しかし、この議論は1つ重大なことを忘れ
Re: (スコア:0)
Re:MVC構造のフレームワークということは (スコア:1)
MSのASPや、.Net FrameworkのASP.NETは自画面へのポストバックが基本だという概念で設計されてるからな~。
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: (スコア:0)
> ただ…ゲンジツのアンケンとしては何故か未だにサーバサイドWebアプリを欲しがる愉快な顧客が多いというのも事実。
一般消費者向けのWebサイトならともかく。
説明して理解してもらえないような客ならとっとと縁を切りましょう。
よほど利率がいいならともかく、ウザい客は遠慮無く切るのがコンピューター業界の鉄則です。
君が受ける地雷案件は、誰かが受けなかった地雷案件であり、君が受けなかった地雷案件は、同業他社が受ける地雷案件なのです。
もし、地雷案件を避ける余裕すらないのなら、残念ながらその会社のビジネスモデル自体が終わってます。
そんな会社とはとっととおさらばするのが吉ですよ。
Re: (スコア:0)
>説明して理解してもらえないような客ならとっとと縁を切りましょう。
そう簡単にリコンできるんだったら世話ないですよorz
特にこの冷え切ったご時世に。
>一般消費者向けのWebサイトならともかく。
おや?それこそ一般消費者はWeb鯖の実現方法なんて頓着しないのでは?
ふつうの人は実現方法が複数あることすら想像してないように見えます。
不特定「多数」が来るサイトは工数と引き換えにメモリ消費の少なさを実現できる低レベルフレームワークのほうがいい、という意味でしょうか?
Re: (スコア:0)
言いたいことは簡潔にまとめて
Re: (スコア:0)
おれも昔、ステートレスにしたくてurlにずらずらごちゃごちゃ書いたこともあるんだが、「ブラウザのヒストリーを汚す」と評判が悪かった。
Re: (スコア:0)
s/ステートレス/ステートフル/ ですか?
>「ブラウザのヒストリーを汚す」と評判が悪かった
いっそGETじゃなくPOSTにすればブラウザ(のURL欄)のヒストリは汚しませんよ。
アプリ1件につき消費するヒストリも1件。
むしろ画面(遷移)の数だけヒストリを汚しまくる従来型アプリよりも清潔になります。
まあそこまで気にしなくても、
笑っちゃうくらいにごちゃごちゃなURLを大量にヒストリに残してくれちゃうWebアプリは
既に世間に沢山転がっていますし…。