MVCよりもASP.NET Webフォームを優先する場合
マイクロソフトが言ったことを知っています
ASP.NET MVCはWebFormsの代わりにはなりません。
また、一部の開発者は、WebFormsはMVCよりも開発が速いと言っています。しかし、コーディングの速度はテクノロジーの快適さのレベルまで下がるので、そのような答えは欲しくないと思います。
ASP.NET MVCを使用すると、開発者はアプリケーションをより詳細に制御できますが、なぜWebFormsは廃止されたと見なされないのですか？あるいは、新しい開発のために、MVCよりもWebフォームを優先する必要があるのはいつですか。
Webforms対MVCは今、ホットな話題のようです。私が知っているすべての人が、MVCを次の素晴らしいものと宣伝しています。少し手を加えれば大丈夫なようですが、Webフォームの終わりになるとは思いません。
私の推論、およびWebフォームがMVCよりも選ばれる理由についての推論は、どちらがより優れているかというよりも、ビジネスの観点に関係しています。
時間/お金が、WebフォームがMVCよりも選ばれる最大の理由です。
チームのほとんどがWebフォームを知っていて、それらをMVCで高速化する時間がない場合、生成されるコードは高品質ではない可能性があります。 MVCの基本を学び、ジャンプして、複雑なページを実行する必要があることは、非常に異なります。学習曲線が高いため、予算にそれを織り込む必要があります。
大規模なWebサイトをすべてWebフォームで記述している場合は、Webフォームで新しいページを作成して、サイトに2つのまったく異なるタイプのページがないようにすることができます。
ここでオールオアナッシングアプローチとは言っていませんが、両方の分割がある場合、特にチームの全員がMVCに精通していない場合は、コードの保守が難しくなります。
私の会社は最近、MVCで3つのテストページを実行しました。私たちは座ってそれらを設計しました。私たちが遭遇した1つの問題は、ほとんどの画面の同じページに表示機能と編集機能があることです。最終的に、ページに複数のフォームが必要になりました。マスターページを使用しない場合を除いて、大したことはありません。 WebフォームページとMVCページの両方が共通のルックアンドフィールのために同じマスターページを使用できるように、それを修正する必要がありました。これで、ネストの追加レイヤーができました。
適切なMVC分離に従うように、これらのページのまったく新しいフォルダー構造を作成する必要がありました。
3ページ分のファイルが多すぎると感じましたが、それは私の個人的な見解です。
私の意見では、MVCを使用するようにサイトを更新するために投資する時間/お金がない場合は、MVCよりもWebフォームを選択します。これに対して半分嫌なアプローチをするならば、あなたが現在持っているウェブフォームよりも良くなることはありません。さらに悪いことに、この技術が台無しになった場合、上層部が彼らが知っているものよりも劣るものとしてそれを見るかもしれないので、あなたが会社の失敗のためにこの技術をセットアップすることさえできたかもしれません。
私はASP。Net WebFormsアプリケーションを3年間開発し、1日のMVCチュートリアルを実行した後、私は販売されました。MVCは常により良いソリューションです。なぜですか？
- ページのライフサイクルはよりシンプルで効率的です
- HTMLコントロール以外にコントロールなどはありません。 ASP .Netが生成しているものを確認するために、出力をデバッグする必要はありません。
- ViewModelsは非常に強力であり、手動制御のバインドを行う必要をなくし、バインドに関連する多くのエラーを排除します。
- 1つのページに複数のフォームを含めることができます。これはWebFormsの深刻な制限でした。
- Webはステートレスであり、MVCはWebのアーキテクチャとより密接に一致しています。 WebStatesは、ViewStateを導入することで、状態とそれに伴うバグを紹介します。 ViewStateは自動的に実行され、バックグラウンドで機能するため、常に希望どおりに動作するとは限りません。
- 最近、Webアプリケーションはajaxで動作する必要があります。全ページをロードすることは許可されていません。 MVCは、JQueryを使用してajaxを非常に優れ、簡単かつ効率的にします。
- 1つのページに複数のフォームを含めることができ、アーキテクチャはURLの呼び出しによって駆動されるため、JQueryを使用して編集フォームを現在のページに編集するなど、ajaxが別のフォームをロードするなどのファンキーなことができます。これで何ができるかを理解したら、驚くべきことを簡単に行うことができます。
- ASP .Net WebFormsは、htmlを抽象化しただけでなく、非常に複雑なものです。時々、奇妙なバグに遭遇し、必要以上に長く苦労するでしょう。多くの場合、実際にはそれが何が間違っていたかを確認できますが、それについては何もできません。奇妙な回避策を実行することになります。
- WebFormsは、デザイナーにとって優れたテクノロジーにはなりません。多くの場合、デザイナーはHTMLを直接操作することを好みます。 MVCではビューであり、WebFormsでは半日の作業です。
- Webプラットフォームが進化しているので、WebFormsは追いつきません。これは、HTML5の新しいタグや機能を認識していません。高価なサードパーティ製のコントロールを入手するか、Microsoftが更新を発行するまで待機しない限り、同じものをレンダリングします。
- WebFormsのコントロールは、非常に多くの点でユーザーを制限します。 MVCでは、JQueryライブラリを取得してテンプレートに統合するだけです。
上記の問題のいくつかは、WebFormsの進化に伴ってある程度対処されていることは知っていますが、それは私の最初の経験でした。全体として、プロジェクトで既に使用されていない限り、WebFormsのビジネスケースを見つけるのは非常に困難です。
マイクロソフトで Scott Guthrie 、 MVCエキスパート にメールを送りました。そして、おそらくこの質問に答えるのに最も適した人です。彼は親切に答えてくれました：
「異なる顧客が異なるプログラミング手法を探しており、多くの人がWebFormsを愛していて、それを素晴らしいと思っています。MVCを愛していて素晴らしいと思う人もいます。それが私たちが両方に投資している理由です。」
だから、私にはこれは技術的な問題ではないと言っています。もしそうなら、それはより「ソフトな問題」です。個人的な好みの1つ。これは、あなた方の何人かが言ったことと一致しています。
すべての回答をありがとう。
これは多くの回答がある陳腐化した質問ですが、私がリストすることを期待していたはずの回答はありませんでした。
短い答えは：
- ASP.NETプラットフォームの最新のプログラミング規則と業界で採用されているパターンを使用してWebアプリケーションを適切に構築する場合は、ASP.NET MVCを使用してください。マイナス面としては、HTMLとクライアント側のリソース（Javascript、CSS）がどのように機能するかを理解しているだけでなく、学習曲線が急であるが、つかむと突然終わりに近づくMVCプログラミングの考え方に着手することが期待されます。
- [〜＃〜] gui [〜＃〜] -centric、 RAD（Rapid Application Development） を使用している、または使用したい場合は、ASP.NET Webフォームを使用します。 、ドラッグアンドドロップアプローチで何かをすばやくプロトタイピングする。つまり、プッシュボタン/データグリッドの動作は15分以内に配線され、ソリューションは開発者がサポートするものではありません。 または、[〜＃〜] gui [〜＃〜] またはWindowsフォーム開発のバックグラウンドがある場合は、ASP.NET Webフォームを使用します。知識をウェブに転送したい。
しかし、これを正しく見るには、それぞれの履歴を理解する必要があります。
ASP.NET Webフォームは、Visual Basic 6 ActiveXコントロール、サーバー上のVB6 DLL、およびASPクラシックを使用して動的Webアプリケーションを構築していた人々に対するMicrosoftの答えでした。当時、これらのMicrosoftツールは本当に混乱していました。Microsoftの出力である.NET Frameworkの全体が、本質的にWindowsスタックで生産的なビジネスプログラミングを行う方法について図面に戻っており、ASP.NET Webフォームは、その日、驚くほど美しい。
全体的なアプローチは、開発者にWindowsアプリケーション開発と非常によく似たものの両方の長所を提供することでしたが、インターネットサービスの力を備えていました。アイデアは、VB6/WinForms "フォーム"（ウィンドウ）と同様にWebページはフォーム（ウィンドウのように、参照）そして、そのフォーム上で、ラベル、テキストボックス、データグリッド、ボタン、およびVB/WinForms GUI開発者が慣れている他のものをドラッグアンドドロップできます。
ボタンに何かを実行させるには、ボタンをドラッグアンドドロップした後、デザイナーでボタンをダブルクリックし、コードエディターでブームし、「クリック」イベントが発生したときに何をするかをフォームに指示します。 これは、Windows GUI開発者が [〜＃〜] gui [〜＃〜] VB6のツールと競合ツールを使用してソフトウェアを作成した方法とまったく同じです現在、コードはサーバー上で実行されています！うわー！
これは2002年の技術でした。インターネット対応の回答として、驚くほど美しい[〜＃〜] gui [〜＃〜][〜＃〜] radのソリューション[〜＃〜] 開発、それは達成する必要のあるビジネス目標を持っていたソフトウェア開発者の乱雑な世界に力の感覚をもたらしました。
残念ながら、このプログラミングモデルは、Windows GUIプログラミングの比喩を非常に強調しているため、必要な実装の詳細、イベントのライフサイクルに対応するために必要なすべての厄介な手荷物、および単純なHTMLの醜い詳細とこれらのドラッグアンドドロップコンポーネントとコントロールが出力するスクリプト。そして結局のところ、実際のアプリケーションをサポートする開発者は、必然的にこれらのコンポーネントを深く掘り下げるか、独自に作成する必要があり、その結果、このインフラストラクチャとの戦い、くずの山に山を残す戦い、髪を引っ張る戦い、そして涙。
バックアップ。手を洗う。ビジネスの問題をもう一度見てみましょう。私たちのビジネス目標は何ですか？
webアプリケーションを構築して管理する必要があります。私たちの制約は、HTTP、HTML、Javascript、CSS上にあるWorld Wide Webがあり、サーバー上にビジネスルール、データベース、および少数の優れたプログラミング言語（C＃など）があることです。開発方法論を推進するために、このWindows GUIのメタファーが本当に必要なのでしょうか。なぜアプリケーションの問題だけに集中して、GUIのメタファを廃止できないのでしょうか。
これがASP.NET MVCの出番です。それは、適切で純粋なソフトウェア開発の原則に戻りたいと思っていた "Alt.Net"と名乗った開発者の反逆から始まりました。もう大騒ぎする必要はありません。ビジネス目標とソフトウェアのベストプラクティスに焦点を当てるだけです。
この場合、これは実際には次のように変換されます。
- 懸念の分離。たとえば、データコンポーネントは、データがどのようにレンダリングされるかを知る必要も、データベース接続構成の詳細でマークアップを表示する必要もありません。このようにして、開発者は編集時の関心領域に集中できます。テストコード。
- HTMLと関連リソースの重要な要点への公開と完全なサポート。 Webフォームでは、HTMLは隠されており、開発者はそのことに煩わされることはありません。 ASP.NET MVCでは、開発者はこれらの詳細を管理する奨励されています。実際、それは必要です。ここでの利点は、開発者がHTML、CSS、およびスクリプトのクリーンなセマンティクスを理解することを再学習し、それに対してで動作することです。
- ビジネスオブジェクトのテスト容易性。コントローラーとモデルは、プログラムによる単体テストに非常に適しているため、実装を検証してビジネス目標を達成し、変更が壊れないことを確認できます。 Webフォームでは、コンポーネントを個別にテストするように設計されておらず、開発出力全体がページフォームとそのビジネスロジックとプレゼンテーションの組み合わせによるイベントライフサイクルに関係していたため、テストが困難でした。ロジックが深く絡み合っています。
Javascriptが高水準プログラミング言語であるように、HTMLはすでに非常に高水準のマークアップ言語であることに注意してください。アセンブリ言語とCを扱っていれば、全体の話は違っていただろう。
次に、＃2を拡張して、ASP.NET MVCの別の目的は、開発者がソリューションの「ビュー」部分のフロントエンドの詳細を編成し、業界の他の部分が構築した豊富な基盤を利用できるようにすることですフロントエンドクライアントプラットフォーム。
ASP.NET MVCの開発者は、サーバー側のアーキテクチャと戦うことなく、豊富なJavascriptライブラリとクライアント側のテンプレート技術を使いこなすのに慣れていることがわかります。これは、ASP.NET Webフォームには本来当てはまりませんでした。なぜなら、本当にその場合、注意してください、それは心臓の弱い人のためではありません。
私はASP.NET MVCに完全に完全に変換しており、振り返ることはありません。それでも、いくつかの非常に大きなWebFormsアプリを維持する必要があると言いました。これが私の見解です。
WebForms
グリッドを使用するためにかなりの重労働がある場合は、これらを使用してください。表形式でうまく収まるシンプルなデータセットがあり、ユーザーがレコードを更新するための簡単な方法を提供したい場合、グリッドコントロールは非常に優れています。はい、MVC 4には非常に洗練されたAjaxリストタイプのものがあり、それがうまく機能することは知っていますが、私たちのビジネスでは、昨日何かを実行する必要があり、古き良きグリッドがうまく機能し、ユーザーは満足していますグリーでグリッド全体をタブで移動できます。私にとっては、これがWebFormsの一番の利点です。しかし、 Ryan が指摘したように、Webフォームは、気の利いたコードビハインドファイルからフェンスの両側を再生しているため、非常に時間の無駄になる可能性があります。すべてのコントローラータイプのものをビューと混在させるために、バラと棘の両方にすることができます。
[〜＃〜] mvc [〜＃〜]
これを使用して、自分でロールバックしたい場合に、アプリケーションを最初から開始する機会があります。明確に定義されたMVCアプリケーションを用意することは、始めるには少し手間がかかりますが、保守性におけるその利点は、初期セットアップコストを上回ります。興味深いAjaxインタラクションを実行したい場合は、クリーンなURLやルートなどのコードを使用してモデルを記述し、アプリのフロー全体を制御できるようにすることをお勧めします。最初は慣れるまでに少し時間がかかりますが、グリーンフィールドアプリにはより良いオプションだと思います。
結論として、私にとってそれはグリッドと！グリッドに帰着します。 :)
私の経験：
- CakePHPプロジェクトを1年間書きました。
- 中規模のWebformsプロジェクトを6か月かけて完成させました。
- Windowsフォームプロジェクトに3年間従事しました。
その経験の後、私はウェブフォームを使用して別のアプリを作成しようとしましたが、ウェブフォームがhtml、javascript、cssを使用するアプリケーションを開発しているという現実から開発者を保護しようとする試みに約1日苦労した後、イライラしました。
その後、MVCを試してみて、出力を直接制御できるようになり（そして、CakePHPのMVCパラダイムの経験もある）、そのシンプルなアプリを1日約1/2で思い通りに完成させることができました。
JQueryのような強力なUIフレームワークを利用できるため、出力が直接制御されることをあきらめ、事前に構築されたかさばるUIコンポーネントを頻繁に使用する利点がなくなります。
私の背景はWindows開発であるため、私はWebフォームを好みます。
開発速度は重要な問題であり、問題をインドの誰かに一夜でフォームで修正するために簡単に問題を渡すことができます。また、ページに速度の問題がある場合、asp.netの速度に関する非常に優れた本が便利です（リックキーシグは男です）。
webformsはex windows peopleのためのものですmvcはweb peopleのためのものです
しかし、リックが素晴らしい本を書いている現代の世界では、サーバーは毎日高速化されており、インドの安価なコーダーもそうです、ウェブフォームにはエッジがあります
私の2セントは、オプションがある場合、新しいプロジェクトには常にASP.NET MVCを使用することです。私の意見では、webformsはWebアプリを開発するための良い方法ではありません。
基本を抽象化するREST悪い、ポストバックモデル全体が悪い、GUI /エディタに依存してhtml/cssを渡す方法が悪い、ウィザードやGUIなどに重点を置くものを設定することは悪いです、URLは悪いです。
私はすべての答えを読みましたが、私の個人的な経験が上記の答えに何かを追加すると思います。
3〜4年前、Webformsを使用して2〜3のWebサイトプロジェクトを開発しました。その頃、MVCがなかったか、聞いていませんでした。開発は当然（私は以前にWeb開発の経験のないWin-forms開発から来ていました）、HTMLを詳細に学習する必要がなく、Webコントロールが大いに役立ったので（非常に多くのことで、生活が楽になりました） 。
さて、それまでずっと、私は最近までWebプロジェクトに取り組んでおらず、単にWPFを使用していくつかのWindowsアプリケーションを構築していました。
数日前、ウェブサイトのアイデアがあり、それを開発することを考えました。今回はMVCで回っています（どこでも話されているため、どちらかを学ぶ必要があるので、MVCを選択します）。私はまだ学び、一緒に構築しているので、プロジェクトはまだ開発段階にあります。
したがって、私がb/wで見つけた主な違いは次の2つです。
Windows開発者の場合、Webフォームは常に有利です。 Windows開発者にとってのAsp.netの学習曲線は少し急です
他のいくつかのテクノロジーでのWeb開発から来る人にとって、MVCはそれらすべての最新のものを模倣しているので好まれます。
HTMLとCSSに関する十分な知識があれば、MVCでの開発はより簡単でクリーンになります
展開はまだ問題です。 Webフォームでは、コピーと貼り付けを行う必要があるだけです。しかし、これにはいくつかのことを行う必要があります。
つまり、どちらもしばらくここにいることになります。
この考慮事項がこのスレッドに対する既存の15の回答の中で提案されたことはまだわかりませんが、検討する価値はあると思います。
私の経験から、WebフォームはMVCよりもWinフォームやWPFに似ています。これを踏まえると、チームがその種の技術に最も経験がある場合、またはWebフォームプロジェクトが既存の（または同時に開発された）Winフォームと同じデータセットにインターフェイスを提供する場合に、Webフォームの選択を検討する人がいるかもしれません。 WPFプロジェクト。そうすることで、開発者はプロジェクト間を簡単に行き来できるようになります。これは、アプリケーションロジックが2つの間で非常に似ているためです。
他の回答が指摘しているように、MVCフレームワークでの開発は、Ruby、PHP、Pythonなど）でのWeb開発により似ているため、当然、MVCの選択は、チームはこれらの領域での経験と、他の回答で提出された要因を一緒に扱います。
数年前にMVCに参加しなかった理由は、Microsoftの未熟なテクノロジだったからです。過去数年間、私たちは現在より成熟したバージョン（4）を使用しており、MSはこれをどのように進めているのかを考え出したようです。ただし、バージョン4で使用する機能にはWindows 2012サーバー（IIS8を介したWebソケット）が必要であるため、MVCを使用して主要なLOBアプリを開発することはまだためらっています。あと1年で、より多くのサードパーティのコントロールが利用可能になり、テクノロジーが安定し、それをサポートするインフラストラクチャーが完成するので、MVCをより受け入れるようになると思います。
この決定は、あなたの好み、あなたの要求、またはあなたの知識と経験にさえ依存します。
トレーニング学習MVCの時間、または配信を取得する時間。これらすべては、1つまたは他のアプローチを選択するために重要です。
どちらかが他より優れているということではなく、単にアプローチとフレームワークの両方に長所と短所があります。
個人的に私はMVC 3を好みます。私はあなた自身の体験を試すことをお勧めしますが、MVCのプログラムはクリーンで楽しく、柔軟で、拡張可能で、安全で構造化された方法であると言う必要があります。
よろしく、
MVCの代わりにWebフォームを選択する唯一の理由は、MVCよりもWebフォームのサードパーティUIコントロールがはるかに多いためです。私はMVCを選択しました。WebFormsでの作業が多すぎて、何か新鮮で新しい作業をしたいのですが、それでもMSショップからです:)
基本的に、WebFormsでビューステートをオフにして、モデルバインディングやサーバー側のコントロールの代わりにViewModelとif/forループを使用することを妨げるものはありません。
これはWebフォームまたはMVCコードですか？
<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>
WebFormsで見つけた唯一の制限は、Dependency Injection/Inversion of Controlを使用する場合、WebFormsページにはパラメーターのないコンストラクターが必要なので、プロパティインジェクションを使用する必要があるため、コンストラクターインジェクションを使用できないことです。これは本当に大したことですか？
私の意見では、それらは十分に関連しており、好みに帰すべきものとほぼ同じ機能を持っています。
優れたWebForms開発者は、優れたMVC開発者と同等に強力な製品を作成できます。しかし、自分自身にMVCの採用を強制しようとする優れたWebForms開発者は、足りなくなるでしょう。 WebFormsを試してみる素晴らしいMVC開発者も同じです。
これらは完全に別個のエンティティではなく、Microsoftが両方をサポートしている限り、それぞれに例外的な開発者の混合グループが引き続き表示されると思います。
ASP.NET MVCは本当にRubyへの答えであり、ブラウザー（クライアント）をサーバーから可能な限り切り離す、新しくトレンディな（IMO）より良い方法です。
ASP.NET Webformsを使用すると、サーバー側からクライアントを大幅に制御でき、ほとんどすべてに直接アクセスできます。基本的に、ビューとコントローラーは1つにまとめられているため、多くの機能が提供され、ほとんどの場合、多くの混乱が生じます。
ASP.NET MVCは、.aspxファイルとそれに付随する.aspx.csファイルの密結合をWebフォームで分離することにより、ビューとコントローラーを分離します。
基本的に、違いは、ビューファイルにデータをdisplay表示するための処理の多く（通常はすべて）を持ち、ビジネスロジックと残りの部分を残すことです。コントローラーでは、慣例により両方をよりクリーンに保ちますが、webformsが許可するよりも相互へのアクセスを少なくします。
まあ、WebFormsはより多くの学習リソースを利用できます（単にそれが古いという事実のために）。したがって、「知っている」わけではない新しいプログラマーは、MVCのような新しいものとは対照的に、この古いテクノロジーに関する情報を見つける可能性が高くなります。 。
上級/経験豊富なプログラマーは年をとっていて、新しいテクノロジーよりも長くプログラミングされているため、古いテクノロジーに熟練しています。
WebFormsアプリケーションのようにMVCに精通するためにお金と労力を費やすことができない限り、新しいプラットフォームへのアップグレードをできるだけ長く延期することは間違いありません。
したがって、いくつかのロジスティック上の問題があります。MVCの利点は、品質と展開時間の短縮という点でコストを上回っていますか？完全にWebFormsで記述されたサイトがある場合、MVCをそれに統合するのに労力とお金をかける価値はありますか？
以前のコメンターが述べたように、MVCは、WebFormsでできるのと同じレベルのコントローラーとのインターフェースを実現することもできません。私はすべて、「ユーザーが物事を詰め込んだり、学習したりしない」ようにすることを目指していますが、チームが書くパラダイムに熱狂的に固執するプログラムを展開/実装することは、それでも不合理に面倒な場合があります。
私たち全員が使用するテクノロジーに精通していると仮定すると、これはすべて個人的な選択です。私は長年WebForms設計アプローチを使用してきましたが、唯一の欠点は、その単純化されたアプローチのため、多くの人々がその膨大な機能を発掘するために時間をかけないことです。
私は最近MVCを使用してプロジェクトを完了しました。アプリケーション開発への設計アプローチ（これにより、より詳細な制御、クリーンなURL、SOCなどを提供します）は非常に気に入っていますが、WebFormsが提供するものは実際にはあまりありません。実際、jQueryの登場とWebフォーム（およびMVC）との連携により、これらの議論はそれほど問題になりませんでした。また、MVCがMVPよりも優れている点として懸念の分離について語るときは、オブジェクト指向プログラミングについてどれだけ知っているか、抽象化とポリモーフィズムの原則をどの程度活用するかを尋ねます。
現在、両方のテクノロジーを快適に使用しており、状況に応じて選択しています。率直に言って、それはあなた次第ですが、特定のテクノロジーが何ができるかを深く学ぶために誰もが時間をかけるとは限らないというのが真実です。
プログラミングの問題に直面したとき、私はよくWebで答えを探します。 Webformsには、ほとんど何でもするための大量の情報/コンポーネントがあります。 MVCでは、オンラインのソースが少なく、何かを機能させるために必要な抽象化のレイヤーが原因で、私がかつてできることには限界がありました。 MVCの合計は、開発者としての私の生産性を損ないますが、Webformsではそうではありません。だから今のところ、MVCがそれを置き換えるのに十分成熟するまで、Webフォームに固執しています。