MVCよりもASP.NET WebFormsを優先する場合

マイクロソフトが言ったことを知っています

ASP.NET MVCはWebFormsの代替ではありません。

また、WebFormsはMVCよりも開発が速いと言う開発者もいます。しかし、コーディングの速度はテクノロジーの快適レベルにまで下がると思いますので、そのような答えは必要ありません。

ASP.NET MVCを使用すると、開発者はアプリケーションをより細かく制御できるため、WebFormsが時代遅れと見なされないのはなぜですか？あるいは、新しい開発のためにMVCよりもWebFormを優先すべき場合はいつですか？

Webforms vs. MVCは現在、ホットなトピックのようです。私が知っている誰もがMVCを次の素晴らしいものだと宣伝しています。私のちょっとした手間から、それは大丈夫のようですが、いいえ、私はそれがウェブフォームの終わりになるとは思いません。

私の推論、およびWebフォームがMVCよりも選ばれる理由に関する推論は、一方が他方より優れているというよりも、ビジネスの観点に関係しています。

時間/お金は、MVCよりもウェブフォームが選ばれる最大の理由です。

あなたのチームのほとんどがウェブフォームを知っていて、MVCでそれらを高速化する時間がない場合、生成されるコードは品質が低い可能性があります。MVCの基本を学習してから、その複雑なページに飛び込んで実行する必要があるのは、非常に異なることです。学習曲線は高いので、予算に織り込む必要があります。

大規模なWebサイトをすべてWebフォームで作成している場合、Webフォームに新しいページを作成して、サイトにまったく異なる2つのタイプのページが含まれないようにすることができます。

ここですべてかゼロかのアプローチだとは言っていませんが、両方が分かれている場合、特にチームの全員がMVCに精通していない場合は、コードの保守が難しくなります。

私の会社は最近、MVCで3つのテストページを実行しました。座ってデザインしました。私たちが遭遇した問題の1つは、ほとんどの画面で同じページに表示機能と編集機能があることです。ページに複数のフォームが必要になりました。マスターページを使用しない場合を除いて、大したことはありません。WebフォームページとMVCページの両方が共通のルックアンドフィールに同じマスターページを使用できるように、それを修正する必要がありました。これで、ネストの追加レイヤーができました。

適切なMVC分離に従うように、これらのページ用にまったく新しいフォルダー構造を作成する必要がありました。

3ページのファイルが多すぎると感じましたが、それは私の個人的な意見です。

私の意見では、MVCを使用するためのサイトの更新に投資する時間/お金がない場合は、MVCよりもWebフォームを選択します。あなたがこれに対して半ばひどいアプローチをするならば、それはあなたが今持っているウェブフォームより良くなることはないでしょう。さらに悪いことに、このテクノロジーが台無しになった場合は、上層部の経営陣が彼らが知っていることよりも劣るものと見なす可能性があるため、このテクノロジーを失敗に設定することさえできます。

ASP .Net WebFormsアプリケーションを3年間開発し、MVCチュートリアルを1日行った後、販売されました。MVCはほぼ常に優れたソリューションです。どうして？

• ページのライフサイクルはよりシンプルで効率的です
• htmlコントロール以外のコントロールはありません。出力をデバッグして、ASP .Netが生成しているものを確認する必要はありません。
• ViewModelを使用すると、非常に強力になり、バインドを手動で制御する必要がなくなり、バインドに関連する多くのエラーがなくなります。
• 1ページに複数のフォームを含めることができます。これはWebFormsの重大な制限でした。
• Webはステートレスであり、MVCはWebのアーキテクチャにより厳密に一致します。Webformsは、ViewStateを導入することにより、状態とバグを紹介します。ViewStateは自動でバックグラウンドで動作するため、常に希望どおりに動作するとは限りません。
• 最近、Webアプリケーションはajaxで動作する必要があります。これ以上ページ全体をロードすることは受け入れられません。MVCは、AjaxをJQueryで非常に優れた、簡単かつ効率的なものにします。
• 1ページに複数のフォームを置くことができ、アーキテクチャはURLの呼び出しによって駆動されるため、JQueryを使用して現在のページに編集フォームのような別のフォームを読み込むajaxなどのファンキーなことができます。これで何ができるかを理解したら、驚くべきことを簡単に行うことができます。
• ASP .Net WebFormsは、htmlの抽象化だけでなく、非常に複雑なものです。時々、奇妙なバグが発生し、必要以上に長い間苦労することになります。多くの場合、あなたは実際にそれが間違っていたことを見ることができましたが、あなたはそれについて何もすることができません。あなたは奇妙な回避策を行うことになります。
• WebFormsは、デザイナーにとって優れたテクノロジーではありません。多くの場合、デザイナーはHTMLを直接操作するのが好きです。MVCではビューであり、WebFormsでは半日です。
• Webプラットフォームは急速に進化しているため、WebFormsは追いついていません。HTML5の新しいタグや機能を認識していません。高価なサードパーティコントロールを取得するか、Microsoftが更新を発行するのを待たない限り、同じものをレンダリングします。
• WebFormsのコントロールは、多くの点で制限されます。MVCでは、JQueryライブラリを取得してテンプレートに統合できます。

WebFormsが進化するにつれて、上記の問題のいくつかがある程度対処されたことは知っていますが、それは私の最初の経験でした。全体として、プロジェクトで既に使用されていない限り、WebFormsのビジネスケースを見つけることは非常に難しいと思います。

MicrosoftのMVCエキスパートであるScott Guthrieにメールを送りました。そして、おそらくこの質問に答えるのに最も資格のある人です。彼は親切に答えてくれました。

「さまざまな顧客がさまざまなプログラミングアプローチを探しており、WebFormsを愛し、それが素晴らしいと考えています。MVCを愛し、それが素晴らしいと考える人もいます。それが両方に投資している理由です。」

だから、私にとってこれは技術的な問題ではないと言う。あなたがそうするなら、それはより「ソフトな問題」です。個人的な好みの一つ。これは数人が言ったことと一致しています。

すべての答えをありがとう。

これは多くの答えがある古い質問ですが、リストに載っていると思われる答えがなかったものはありません。

短い答えは次のとおりです。

• ASP.NET MVCを使用するのは、ASP.NETプラットフォーム用の最新のプログラミング規則と業界に組み込まれたパターンを使用してWebアプリケーションを適切に構築する場合です。欠点としては、HTMLとクライアント側のリソース（Javascript、CSS）がどのように機能するかを知ることが期待されるだけでなく、急な学習曲線を持っているが一度把握すると突然終了するMVCプログラミングの考え方を身に付けることができます。
• GUI中心のRAD（Rapid Application Development）を使用している、または使用したい場合は、ASP.NET Webフォームを使用します。 15分。このソリューションは、開発者がサポートするものではありません。または、GUIまたはWindowsフォーム開発のバックグラウンドがあり、知識をWebに転送したい場合は、ASP.NET Webフォームを使用します。

しかし、これを適切に見るには、それぞれの歴史を理解する必要があります。

ASP.NET Web Formsは、Visual Basic 6 ActiveXコントロール、サーバー上のVB6 DLL、およびASP Classicを使用して動的なWebアプリケーションを構築していた人々に対するMicrosoftの回答でした。当時、これらのMicrosoftツールを使用したWeb開発は非常に面倒でした。Microsoftの出力である.NET Framework全体が、Windowsスタックで生産的なビジネスプログラミングを行う方法について基本的に図面に戻っていたのと同様に、ASP.NET Web Formsはその当時、驚くほど美しいものでした。

全体的なアプローチは、Windowsアプリケーション開発に非常に似ているものの、インターネットサービスの力を活用して、開発者に両方の長所を提供することでした。VB6 / WinFormsの「フォーム」（ウィンドウ）と同様に、Webページもフォーム（ウィンドウのように見える）であり、そのフォームでラベル、テキストボックス、データグリッド、ボタンなど、VB / WinForms GUI開発者が慣れ親しんでいたもの。

ボタンに何かをさせるには、ドラッグアンドドロップした後、デザイナーでボタンをダブルクリックし、コードエディターでブームを開き、その「クリック」イベントが発生したときにフォームに何をするかを伝えます。これは、Windows GUI開発者がVB6のGUIツールと競合ツールを使用してソフトウェアを作成した方法とまったく同じでしたが、現在はサーバーでコードが実行されています。うわー！

これは2002年の技術でした。RAD開発用のインターネット対応GUIソリューションへの答えとして、当時は驚くほど美しく、それは達成する必要のあるビジネス目標を持っていたソフトウェア開発者の乱雑な世界に力の感覚をもたらしました。

残念ながら、このプログラミングモデルはWindows GUIプログラミングの比phorを非常に強調しているため、必要な実装の詳細、イベントライフサイクルに対応するために必要なすべての邪魔な手荷物、および単純なHTMLこれらのドラッグアンドドロップコンポーネントとコントロールが出力するスクリプト。そして結局、実際のアプリケーションをサポートする開発者は、これらのコンポーネントを深く掘り下げるか、独自のコンポーネントを作成する必要がありました。その結果、彼らはこのインフラストラクチャとの戦い、涙。

バックアップします。手を洗ってください。もう一度ビジネスの問題を見てみましょう。私たちのビジネス目標は何ですか？

Webアプリケーションを構築および管理する必要があります。私たちの制約は、HTTP、HTML、Javascript、CSS上にあるWorld Wide Webがあり、サーバー上にビジネスルール、データベース、少数の優れたプログラミング言語（C＃など）があることです。開発方法論を推進するために、このWindows GUIのメタファーが本当に必要なのでしょうか？なぜアプリケーションの問題に集中し、GUIのメタファーを廃止できないのですか？

これがASP.NET MVCの出番です。それは、適切で純粋なソフトウェア開発の原則に戻りたいと自らを「Alt.Net」と呼んだ開発者の反乱によって始まりました。面倒なことはもうせず、ビジネス目標とソフトウェアのベストプラクティスに集中してください。

この場合、これが実際に意味するものは次のとおりです。

1. 懸念の分離。たとえば、データコンポーネントは、そのデータがどのようにレンダリングされるかを知る必要も、マークアップをデータベース接続構成の詳細に邪魔する必要もありません。このようにして、開発者は編集およびテストコード。
2. HTMLと関連リソースの核心への露出に対する露出と完全なサポート。Webフォームでは、HTMLは隠されており、開発者はこれに煩わされることをお勧めしません。ASP.NET MVCでは、開発者はこれらの詳細を管理することが推奨されます。実際、それは必要です。ここでの利点は、開発者がHTML、CSS、およびスクリプトのきれいなセマンティクスを鑑賞するために再学び、働くことができるということであるとのことではなく、それに反対。
3. ビジネスオブジェクトのテスト可能性。コントローラーとモデルは、プログラムによる単体テストに非常に適しているため、実装を検証してビジネス目標を達成し、変更が破損しないことを検証できます。Webフォームでは、コンポーネントを個別にテストするように設計されておらず、ビジネスロジックとプレゼンテーションロジックが深く絡み合っているため、開発出力全体がページフォームとそのイベントライフサイクルを中心に展開されるため、テストが困難でした。

HTMLはすでに非常に高度なマークアップ言語であり、Javascriptは高度なプログラミング言語であることに注意してください。アセンブリ言語とCを扱っていた場合、全体の話は違っていただろう。

＃2を展開すると、ASP.NET MVCのもう1つの目的は、開発者がソリューションの「ビュー」部分のフロントエンドの詳細を整理し、他の業界が構築した豊富な基盤を活用できるようにすることです。フロントエンドクライアントプラットフォーム。

ASP.NET MVC開発者は、サーバー側のアーキテクチャと戦うことなく、豊富なJavascriptライブラリとクライアント側のテンプレートテクニックを利用することに慣れていることがわかります。これは、ASP.NET Webフォームでは元々そうではありませんでした。なぜなら、WebフォームではHTMLやスクリプトをまったく見たくないからです。ただし、本当に必要な場合を除き、その場合は気をつけてください。心の。

私はASP.NET MVCへの完全かつ完全な変換を行っていますが、振り返ることはありません。非常に大きなWebFormsアプリをいくつか維持する必要があると言いました。これが私の見解です。

WebForms
これらは、グリッドに関係する深刻な重荷がある場合に使用します。グリッドコントロールは、表形式にうまく適合する単純なデータセットがあり、ユーザーがレコードを更新するための簡単な方法を提供したい場合に非常に便利です。はい、MVC 4には非常におしゃれなAjaxリスト型のものがあり、それがうまく機能することはわかっていますが、私たちのビジネスでは、昨日何かを実行する必要があることが多く、古き良きグリッドがうまく機能し、ユーザーは満足していますグリーでグリッドをタブで移動できます。私にとって、それは私にとってWebFormsについて本当に最高のことです。しかし、ライアンとして気の利いたコードビハインドファイルからフェンスの両側を再生しているため、WebFormsは大きな時間の混乱になる可能性があると指摘しました。コントローラー型のものをすべてビューと混在させておくと、同時にバラととげの両方になる可能性があります。

MVC
独自にロールバックしたいときに、アプリケーションを最初から開始する機会がある場合に使用します。明確に定義されたMVCアプリケーションを持つことは、開始するのにもう少し手間がかかりますが、保守性の利点は初期セットアップコストを上回ります。興味深いAjaxインタラクションを行いたい場合は、きれいなURLやルートなどのコードを使用してモデルを作成し、アプリのフロー全体を制御できるようにすることをお勧めします。最初は慣れるまでに時間がかかりますが、グリーンフィールドアプリの方が良い選択肢だと思います。

結論として、私にとっては、グリッドと！gridsに帰着します。:)

私の経験：

• 1年間CakePHPプロジェクトを作成しました。
• 6か月にわたって中規模のWebformsプロジェクトを完了しました。
• Windows Formsプロジェクトで3年間働いた。

その経験の後、私はウェブフォームを使用して別のアプリを書いてみましたが、html、javascript、cssを使用するアプリケーションを開発しているという現実からウェブフォームが開発者を保護しようとする方法で約1日苦労した後、イライラしました。

その後、MVCを試してみて、出力をより直接制御しました（そしてCakePHPのMVCパラダイムのいくつかの経験がありました）そのシンプルなアプリを1日約1/2で思い通りに完成させることができました。

jQueryのような強力なUIフレームワークを使用できるため、出力の直接制御を放棄して、しばしばかさばるビルド済みのUIコンポーネントを使用するという魅力がなくなります。

私の背景はWindows開発であるため、私はWebフォームを好みます。

開発速度は重要な問題であり、フォームで一晩修正するためにインドの誰かに問題を簡単に渡すことができます。また、ページに速度の問題がある場合、asp.netの速度に関する本当に良い本は便利です（リックKiessigは男です）。

webformsはex windows向けですmvcはweb向けです

しかし、リックが素晴らしい本を書いた現代の世界では、サーバーが毎日速度を上げており、インドの安価なコーダーがいます。

私の2セントは、オプションがあれば新しいプロジェクトに常にASP.NET MVCを使用することです。私の意見では、ウェブフォームはウェブアプリを開発する良い方法ではありません。

基本的なRESTを抽象化するのは悪い、ポストバックモデル全体が悪い、html / cssがGUIエディターに依存する方法が悪い、悪いものをセットアップするためのウィザードやGUIなどに重点を置くのは悪いと思う悪いです。

私はすべての答えを読んで、私の個人的な経験が上記の答えに何かを追加すると感じています。

3〜4年前、Webformsを使用して2〜3のWebサイトプロジェクトを開発しました。その頃、MVCは存在しなかったか、聞いたこともありませんでした。開発は自然に（私は以前のWeb開発経験のないWinフォーム開発から来ていました）、私はHTMLを詳細に学ぶ必要がなく、Webコントロールが大いに役立ったので（地獄、それは人生を楽にしました） 。

今、すべての時間の後、私は最近までWebプロジェクトを操作せず、単にWPFを使用していくつかのWindowsアプリケーションを構築していました。

数日前、私はウェブサイトのアイデアを思いつき、それを開発することを考えました：今回はMVCで回っていました（どこでも話したので、どちらかを学ぶ必要があるので、MVCを選択します）。私はまだ一緒に学び、構築しているので、プロジェクトはまだ開発段階にあります。

だから、私が見つけた主な違いは2つあります：-

• Windows開発から来た人にとって、Webフォームは常に有利です。Windows開発者向けのAsp.netの学習曲線は少し急です

• 他の技術でのWeb開発から来た人にとって、MVCはそれらすべての最新のものをあざ笑うので好まれます。

• HTMLとCSSの十分な知識を備えている場合、MVCでの開発は簡単でクリーンです

• 展開は依然として問題です。Webフォームでは、コピーと貼り付けを行うために必要なものが1つだけです。しかし、これにはいくつかのことが必要です。

要するに、それらの両方がしばらくここに滞在します。

このスレッドに対する既存の15の回答の中で、この考慮事項をまだ提示していませんが、検討する価値があると思います。

私の経験から、Web FormsはMVCよりもWin FormsとWPFに似ています。これを考えると、チームがその種の技術で最も経験がある場合、またはWeb Formsプロジェクトが既存の（または同時に開発された）Win Formsと同じデータセットにインターフェースを提供する場合、Web Formsを選択することを検討すると思いますWPFプロジェクト。そうすることで、アプリケーションロジックは2つの間で非常に似ているため、開発者はプロジェクト間をより簡単に横断できます。

他の回答が指摘しているように、MVCフレームワークでの開発は、Microsoftの同等品よりもRuby、PHP、PythonなどでのWeb開発に似ています。そのため、当然、MVCの選択は、他の回答で提出された要因とともに、それらの分野でのチームの経験に影響されます。

数年前にMVCに参加しなかった理由は、Microsoftの未熟なテクノロジーでした。過去数年にわたって、私たちは現在、より成熟したバージョン（4）に取り組んでいます。MSは、これをどこに進めるかを考え出したようです。ただし、バージョン4で使用する機能にはWindows 2012サーバーが必要であるため（IIS8を介したWebソケットに関して）、MVCを使用して主要なLOBアプリを開発することには依然として消極的です。あと1年で、より多くのサードパーティ製コントロールが利用可能になり、テクノロジーが落ち着き、それをサポートするインフラストラクチャが整うことを期待して、MVCをさらに受け入れることになるでしょう。

この決定は、あなたの好み、要求、さらには知識と経験に依存します。

MVCの学習トレーニングの時間または配信を取得する時間。これらはすべて、いずれかのアプローチを選択するために重要です。

あるものが別のものより優れているということではなく、単にアプローチやフレームワークの両方に長所と短所があります。

個人的にはMVC 3を好みます。自分で体験してみることをお勧めしますが、MVCのプログラムは、クリーンで楽しく、柔軟で、拡張可能で、安全で構造化された方法であると言う必要があります。

よろしく、

MVCの代わりにWebFormsを選択する唯一の理由は、MVCよりもWebFormsのサードパーティUIコントロールがはるかに多いためです。MVCを選択した理由は、WebFormsを使いすぎており、新鮮で新しいものを使いたいが、それでもMSショップで仕事をしたいからです:)

基本的に、WebFormsでビューステートをオフにし、モデルバインディングとサーバー側コントロールの代わりにViewModelsとif / forループを使用することを妨げるものは何もありません。

これはWebFormsまたはMVCコードですか？

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

WebFormsで見つけた唯一の制限は、Dependency Injection / Inversion of Controlを使用する場合、WebFormsページにはパラメーターなしのコンストラクターが必要であり、プロパティインジェクションを使用する必要があるため、コンストラクターインジェクションを使用できないことです。これは本当に大したことですか？

ASP.NET MVCは、実際にはRubyに対する答えであり、ブラウザ（クライアント）をサーバーから可能な限り分離する新しい、流行の（IMO）より良い方法です。

ASP.NET Webformsを使用すると、サーバー側からクライアントを制御でき、ほとんどすべてに直接アクセスできます。基本的に、ビューとコントローラーは同じものであるため、多くのパワーが得られ、多くの場合混乱が生じます。

ASP.NET MVCは、Webフォームに付随する.aspxファイルと.aspx.csファイルの密結合を切り離すことにより、ビューとコントローラーを分離します。

本質的に、違いは、ビューファイルにデータを表示するための処理（通常はすべて）を大幅に増やし、ビジネスロジックと残りをコントローラーに残し、慣例によりきれいに保ち、それぞれへのアクセスを少なくすることですWebforms以外は許可します。

私の意見では、それらは十分に関連しており、好みに帰すべきだろうとほぼ同じ能力を持っています。

優れたWebForms開発者は、優れたMVC開発者と同等に強力な製品を作成できます。しかし、MVCを強制的に採用しようとしている偉大なWebForms開発者は間もなく登場します。WebFormsを試してみるすばらしいMVC開発者にも同じことが言えます。

これらは完全に独立したエンティティではなく、Microsoftが両方をサポートし続ける限り、それぞれに例外的な開発者の混合グループが見られると思います。

私たちが使用する技術にすべて熟達していると仮定すると、これはすべて個人的な選択です。私は長年WebFormsデザインアプローチを使用してきましたが、唯一の欠点は、単純なアプローチのために、多くの人が膨大な機能を発掘するのに時間をかけないことです。

私は最近、プロジェクトを完了するためにMVCを使用しましたが、アプリケーション開発のデザインアプローチ（制御性の向上、URLのクリーン化、SOCなど）は非常に気に入っていますが、WebFormsが提供できないものはほとんどありません。実際、jQueryの出現とWebForms（およびMVC）での動作により、これらの議論はそれほど問題になりませんでした。そして、MVCがMVPよりも優れているという利点として懸念の分離について話すとき、オブジェクト指向プログラミングについてどれだけ知っているか、そして抽象化とポリモーフィズムの原理をどれだけ活用するかを尋ねます。

私は現在両方のテクノロジーを使用することに満足しており、状況に基づいて選択します。率直に言って、それはあなた次第ですが、真実は特定の技術が何ができるかを深く学ぶために誰もが時間をかけるわけではないということは変わりません。

プログラミングの問題に直面したとき、私はしばしばウェブで答えを探します。Webformsには、何でもできるようにするための情報/コンポーネントがたくさんあります。MVCでは、オンラインのソースが少なくなり、何かを機能させるために必要な抽象化のレイヤーが、私がかつてできることを制限しました。MVC合計は、開発者としての私の生産性を低下させますが、Webformsではそうではありません。だから今のところ、MVCがそれを置き換えるのに十分に成熟するまで、私はWebフォームにこだわっています。

まあ、WebFormsはより多くの学習リソースを利用できるため（単に古いという事実のため）、したがって「知らない」新しいプログラマーはMVCのような新しいものとは対照的にこの古いテクノロジーに関する情報を見つける可能性が高くなります。

シニア/経験のあるプログラマーは年をとっていて、新しいテクノロジーに比べてプログラミング時間が長いため、古いテクノロジーに習熟します。

お金と労力を費やしてWebFormsアプリケーションのようにMVCに精通させることができない限り、新しいプラットフォームへのアップグレードをできるだけ長く控えることになります。

したがって、いくつかの物流上の問題があります。MVCの利点は、品質と展開時間の短縮という点でコストを上回っていますか？完全にWebFormsで記述されたサイトがある場合、MVCを統合するのに労力とお金を費やす価値はありますか？

前のコメンターが述べたように、MVCでは、WebFormsでできるのと同じレベルのコントローラーとのインターフェイスを実現することもできません。私は「ユーザーに物を詰め込ませたり学習させない」という側面に賛成していますが、チームが書くすべてのパラダイムに熱狂的に固執するプログラムを展開/実装することは依然として不合理に面倒です。

これら2つの技術のギャップは、以前ほど広くはないと思います。

• Webフォームは、MVCが使用するルーティングエンジン（または非常によく似たもの）を使用できます。
• スクリプトマネージャーは、スクリプトを組み合わせたり、CDNから読み込んだり、スクリプトの読み込みを遅らせたりすることもできます。

あなたの質問に直接答えるために、私はそれが好みやプロジェクトとは何かに帰着すると思います。どちらも、開発に対して大きく異なるアプローチを採用しています。個人的に私はMVCへの移行に取り組んできましたが、それでもWebフォームでの作業を楽しんでいます。MVCまたはWebformsを使用すべきかどうかの答えは、両方のテクノロジーを体験して決定することだと思います。