私は、mvc と Web フォームがどのように補完的であるかなどについてのマーケティングの話をすべて読みました...
ただし、ブログで話題になっているのは mvc だけのようで、出てくるニュースは mvc に関するものだけです。
Microsoft は Web フォームを一級市民として改善し続けるつもりですか、それとも、時間の経過とともにすべての実際の努力、開発者、およびリソースを mvc に移行するため、単にサポートされるテクノロジになるのでしょうか?
近い将来、Web フォームに新しいエキサイティングな改善が加えられるという実際の証拠はありますか?
11月のPhilHaakの投稿を見るよりも悪いことをする可能性があります。
彼は、昨年PDCでASP.NETの下で発表された5つの重要なことを指摘しています。
それと相まって、ASP.NET MVCの一部として構築されたものがあり、MVCを使用しなくても、ルーティングモジュールのようなWebフォーム用にすでにリリースされています。これは私のプロジェクトの一部で非常に役立ちます。
これらに加えて、VS2010には、WebFormsまたはMVCのいずれかを使用するWeb開発者に役立つ変更がいくつかあります。これは良いことです。
ブロガーは、光沢のある「新しい」ものについて話す傾向があります。それが、物事の進め方です。MVCは新しいデザインパターンではありませんが、そのために多くの単語が書かれているのを目にするはずです。少なくとも、元に戻ります。 30年。
WPF /Silverlightについても同じことが言えます-彼らはWinForms/WebFormsキラーですか？いいえ。これらは代替の製品であり、以前の方法に比べていくつかの利点がありますが、いくつかの違い/欠点もあります。
マイクロソフトは、開発に関する 1 つの基本的な事実にようやく同意するようになりました。どんな問題にも究極の解決策を提供することはできません。これが MVC が開発されている理由であり、Scott Guthrie は、MVC はより大規模でよりエンタープライズ的なサイト向けであると明確に述べています。Web フォームは引き続き存在し、Web 開発に対する単純な RAD ベースのアプローチとして開発されます。
一歩下がって、Microsoft スタックに対する最近の改善点と追加点をすべて確認すると、これら 2 つのクラスに簡単に分類できます。例えば：
どのタスクに対してどのツールを選択すべきかについて、開発者の間で多くの混乱があるように思われるため、Microsoft がこの区別を徐々に明確にしてくれることを願っています。
結論として、Microsoft は、異なる開発者プロファイルに対応しているため、両方の開発を続けると思います。Microsoft は明らかに、開発者ベースを可能な限り拡大し、.NET スタックを可能な限り便利にすることに大きな関心を持っています。
私は会議 (Remix 08) に参加していましたが、Scott Gu は、間違いなく両方の方法を引き続きサポートする予定であり、MVC はすべてのアプリケーションに適しているわけではないと述べました。Scott は、Web フォーム モデルに多くの改善が予定されていると述べました (ただし、それらが何であるかは明らかにしませんでした)。
Web
フォーム モデルは、いくつかの種類のアプリケーションに適しています。たとえば、小規模なアプリ、ビュー ステートを有効に利用するための長いプロセスを必要とするアプリなど、
多くのアプリケーションで使用されてい
ます。多くのサード パーティ コンポーネントが
ASP.net用に開発されています。実装はまだ成熟していません（ただし、これまでのところかなり良いようです）
Microsoft は、おそらく数週間以内に PDC の多数の新機能を発表するでしょう。
ここでは、MVC が「エンタープライズ」フレームワークである、または MVC の方が優れているという一般的な考えに同意しません。
MVCは素晴らしいです！しかし、名前だけ見てください。「モデル、ビュー、コントローラー」の略です...そこにある「ビュー」を参照してください。
競合他社の「Web フォーム」を見てください...その中の「フォーム」が見えますか?
MVC は、「ビュー」タイプの状況で素晴らしい仕事をします。コンテンツ (情報の「ビュー」) を公開するサイトの場合、MVC はおそらく優位性があります。特に、インテリジェントなビューの切り替えをサポートするために多くのテストと非常に正式な設計が必要な大規模システムの場合はそうです。
フォームを介してユーザーと頻繁にやり取りするアプリケーション (データ収集とデータ入力が多いアプリ) の場合、Web フォームは、フォーム投稿を主要なメカニズムとして本来的に使用するため、優位性があります。
Web フォームでビューを実行したり、MVC でフォームを実行したりできますが、それぞれにトレードオフがあります。MVC の現在の状態では、大量のデータ入力 "ビュー" を作成することは、Web フォームよりもはるかに困難で苦痛を伴うことがわかりました。
将来的には、MVC がデータ入力シナリオの処理で改善されることを期待していますが、これらのシナリオは、Web フォームでの処理に比べてかなり高くつく可能性があります。
私が知る限り、どちらも「エンタープライズ」レベルではありません...私が今後最も興味を持っているのは、ビジネスの表示と公開にMVCを使用し、Webフォームがより自然に使用されるハイブリッドアプリケーションです重いデータ入力の終わり...すべて同じWebプロジェクト内...そのようなものが見られることを願っています。
MVC フレームワークの噂が広まり始める前に、私たちは自社で独自の .NET MVC フレームワークの開発にかなりの時間を費やしました。
これは、WebForms の抽象化の制限によって制約されたくなかったためです。WebForms が最も高度にカスタマイズされたアプリケーションによってすべてに課されるように見える「ぎこちない」感触とユーザー インターフェイスの妥協を避けたかったからです。また、使いやすい URI が必要であり、フロントエンド開発とバックエンド開発を Web フォームで提供されるよりも適切に分離したいと考えていました (XML / XSLT アーキテクチャに落ち着きました)。
私の意見では、WebForms は実際には、開発者から HTTP の実際のメカニズムを抽象化する ViewState や PostBacks などを使用するため、ユーザーと対話する方法がはるかに貧弱です。これにより、ユーザーに許可する方法の自由度が低くなります。システムと対話します。典型的な例は、WebForms ページはほとんどの場合 POST の結果であるため、ユーザーがページを更新しようとすると、ブラウザーから不快な警告メッセージが表示されることです。これに対処するための従来の Web 開発の世界におけるパターンは、常に HTTP 応答に 302 Redirect ディレクティブを含めることでした。したがって、GET はデータの取得用であり、POST はデータの送信用であるという元の HTTP パラダイムに固執しています。他の、
とはいえ、RAD にとって WebForms はすばらしいものです。私は現在、カスタム MVC フレームワークを使用して開発した webapp の管理アプリケーションを開発しています。データベース テーブルの負荷の内容を表示するだけでよいため、場合によってはユーザーさまざまな方法でそれらを編集します。
MS が WebForms を引き続きサポートすることを確信する必要がある場合は、すべての元 Windows 開発者のことを考えてみてください。これらは、WebForms が元々開発された人々のために開発されたものであり、なくなることはありません。WebForms のファンなら、企業の開発者が救世主になります。