2

私は、CGIからASP.NetおよびStruts + Spring + Hibernateに至るまで、10 年以上にわたって Web アプリを開発してきました。普及しているアーキテクチャ スタイルは、StrutsやRuby on Railsなどのサーバー支援 MVCのようです。

これらすべてのことから、ウェブの発明によって始まった 15 年間の気晴らしの後、私たちは一巡し始めていると私は信じています。この間、私たちは Web が提供するすべての機能に魅了されてきたので、Web アプリの使いやすさ (および開発者エクスペリエンス) がデスクトップ アプリと比較して劣っていることに気づきませんでした。私たちは今、「くそっ！ Web の利点が大好きですが、使いやすさ、オフライン機能、およびデスクトップとの統合も望んでいます!」と言っているようです。

上記のすべての開発は、プレゼンテーション ロジックを以前の場所、つまりクライアントに戻すという方向に私たちを動かしているようです。誤解しないでほしいのですが、サーバー支援の MVC フレームワークがすぐになくなるとは思いませんが、それらは衰退し、RIAとRDAは増加していると思います。

それで、あなたはどう思いますか？サーバー支援 MVC フレームワークはピークに近づいていますか?

4

2 に答える 2

3

私はある程度同意します-私たちはよりクライアント中心になりつつありますが、これはクライアントが実際に標準化された方法で進歩しているためだと思います。

私たちはクライアントのすべてから始めました-それがすべてだったからです。次に、2つを分離したのはクライアントサーバーでした。その後、1つの理由で、クライアントビットが徐々に間引かれ、サーバーにプッシュバックされました。

クライアントは吸い込まれ（win95、macos <10、unix X11）、展開は悪夢でした。ブラウザの導入は簡単でした。

それはトーを変える。.NET 3.5と同様に、Airは簡単にインストールできます。Airアプリは、WPF Click-onceアプリと同様に、簡単に展開できます（ここをクリックしてください-はいと言ってください）。ネットワークは現在、環境の事実上の一部であり、追加する必要のある特別なものではありません。データベースは、Silverlightアプリ（SQL Server Compact Edition）またはiphone（SqLite）に埋め込むことができるものであり、大きなサーバーが必要なものではありません。

また、すべてが自動更新されるため、インストール後のストーリーが大幅に改善されます。

彼らが衰退しているとは思わない-ロジックは再び押し出されたばかりだと思うし、将来的には引き戻され、押し戻されるだけだと思う​​。

Silverlight / Air / Flashなどはすべて非常に強力ですが、サーバーMVCフレームワークの基盤であるHTML + Javascriptは、特にIE6であるb'stardを無視すると、大幅に進歩しました。

とにかく、HTMLではなくJSONをスローしている場合でも、サーバー支援のMVCフレームワークでRIAのバックエンドを作成します。したがって、彼らはもはやすべてではありませんが、死んでいる（またはピークに達している）にはほど遠いです

于 2008-10-07T14:40:38.220 に答える
1

何かを明確にしましょう！

  1. MVC は、関心を分離するための設計パターンにすぎません。サーバー側のフレームワークとは実際には関係ありません。
  2. 技術的な Web 1.0 や Web 2.0 はありません。JavaScript と Flash は何年も前から存在していました。ソーシャルネットワーキング、タグ付けなどについてのみです。

サーバー側のフレームワークはまったく死んでいません。クライアントのアーキテクチャ/レンダリングが悪い場合は、Nic Wise に同意します。HTML ページを (毎回同じ方法で) 印刷できますか? いいえ、できません。すべてのブラウザー (エンジン) には、HTML 記述の独自の表現があるためです。JavaScript/Flash... は多くの人/企業にとって制限であるという理由だけで、サーバー側の処理は長期間そこにとどまります。

「どこでも走れる」JavaScript の開発は長い間負担でした。最近では、この作業を行う JQuery のようなフレームワークがあります。テンプレート/mvc に EJS (Embedded JavaScript) を使用して、JavaScript で独自のホームページを作成しました。古い肥大化した JSP/PHP ページは、ビジネス ロジックを設計とは異なるものにすることが本当に良いことであることを示しています。

すべての Web アプリケーションの悪い問題は、アプリケーションの状態を保存する場所を決定することです! 悪い方法を選択すると、スケーリングできません。サービス指向のバックエンドを備えたクライアント中心のフレームワークにより、非常に優れたスケーリングが可能になります。

私は SOFEA/SOUI を少し使っています。最も一般的な問題に対応できるフレームワーク スタックがあれば、きっと気に入っていただけるはずです。

Air と Flex は優れていますが、多くの制限があります (Flash/JS など)。Google の Chrome と Gears を使用するには、コンピュータに Google ソフトウェアをインストールする必要があります。この辺りに Gears を持っているのは誰? Gears は、広く配布されている標準として確立されていません。

Hibernate/Spring および Struts の経験がある場合は、Grails を試す必要があります。GWT/FLEX&AIR/SOFEA&SOUI バックエンドを開発したり、古き良きサーバー側の HTML レンダリングを開発したりするのは良いことです。

私が SOFEA/SOUI を気に入っているのは、それほど侵略的ではなく、投資保護 (SOA サービス) と高い再利用率を提供するからです。また、負荷をサーバーからクライアントに移す良い方法でもあります。

于 2009-03-12T13:56:34.730 に答える