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

WebフォームとMVCは、現在ホットなトピックのようです。私が知っている誰もがMVCを次の素晴らしいものだと宣伝しています。少し手を加えただけでは問題ないようですが、Webフォームの終わりになるとは思いません。

私の推論と、MVCではなくWebフォームが選択される理由については、次のように述べています。

MVCよりもWebフォームが選択される最大の理由は、時間とお金です。

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

すべてをWebフォームで記述した大規模なWebサイトがある場合は、Webフォームで新しいページを作成する傾向があります。」サイトに2つの非常に異なるタイプのページがあります。

ここではオールオアナッシングのアプローチだと言っているわけではありませんが、両方が分割されていると、コードの保守が難しくなります。 、特にチームの全員がMVCに精通しているわけではない場合。

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

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

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

私の意見では、MVCを使用するようにサイトを更新するために投資する時間/お金がない場合は、MVCではなくWebフォームを選択します。それはあなたが今持っているウェブフォームよりも良くなることはありません。さらに悪いことに、このテクノロジーが台無しになっていると、会社で失敗する可能性もあります。上級管理職は、このテクノロジーを自分たちが知っているものより劣っていると見なす可能性があるからです。

コメント

• これは良い答えです。あなたの個人的な経験が高く評価されているので+1を与えました。しかし、これは私が避けてほしい開発者の経験/スキルセットの不足による失敗です。 。MVCの学習曲線を恐れているという理由だけで、Microsoftがテクノロジを廃止することを選択しないとは確信していません。これは事実かもしれませんが、私はまだ’確信しました。
• @ P.Brian.Mackey-フォームの開発がMVCよりも速いとは言いませんでした。’あなたはその議論を除外するように依頼しました。スタッフをトレーニングするための時間とお金を議論することは別の議論です。MSは’ 1つの大きな理由でWebフォームを廃止しませんでした：エンタープライズクライアントはWebフォームでWebクライアントを開発するのに何年も費やし、勝ちました’更新に時間とお金を投資する必要があることを親切に考えてください。
• @ Raynos-チームの全員がMVCに習熟していて、あなたの会社が新しいプロジェクトを開始している場合、誰かがWebフォームを選択しているのを見ることができる唯一の理由は個人的な選択です。
• 私は両方のテクノロジーをよく知っています。私のすべてのWebプロジェクトはmvcで行われ、最善のアプローチを自由に行える会社で働いています。私は常にMVCを選択します。
• Webformsから始めて、MVCを見つけたらそれに切り替えました。 ‘誰もがウェブフォームを守る方法がわかりません。ページのライフサイクルとページ全体の1つのフォーム？私をからかってるの？ Yahooサイトビルダーはおそらくその意図された顧客でしたが、彼らでさえ’そのジャンクを望んでいませんでした。

ASP .Net WebFormsアプリケーションを3年間開発し、MVCチュートリアルを1日行った後、売りに出されました。 MVCはほとんど常により良いソリューションです。なぜですか？

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

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

コメント

• +1 for複数のフォームを指摘します。さらに、HTML Webフォームが生成するという事実は、ほとんどの場合、SEOにあまり適していません（たとえば、ページ上部のビューステートの大きなチャンク）
• この回答に100％同意する必要があります。結局のところ、WebFormsは、クライアント側（html /ブラウザー）での作業を非常に困難にします。あなたは文字通り何かを成し遂げるためにフレームワークと戦わなければなりません。 aspxページは、cshtmlページが通常行うよりも、サーバー制御のために非常に多くのコードで終了します。 @šljakerViewStateをオフにし始め、サーバーコントロールを回避すると、’その時点で多くのWebフォームが放棄されます。 ‘その議論が特に説得力があるとは思いません。
• WebFormsでプレーンなhtmlコントロールを使用でき、サーバーコントロールの使用を強制することはできません。完全なステートレスWebフォームを作成でき、ViewStateの使用を強制することはできません。 Webフォームでは完全なajaxとjQueryを使用できますが、jQueryの使用を制限している人はいません。 URLルーティングを実装できます。静的ファイルベースURLの使用を強制する人は誰もいません。 CSSを使用して手動でページを描画すると、MVCが必要とするだけの時間が消費されます。 HTMLページはWebform上で直接設計できます。
• @mjb：サーバーコントロールやViewStateなどを使用しない場合’、WebFormsを使用する理由MVCは、’実行していることに近いですか？ ‘は、トラクターを運転して仕事をするようなものですが、オフロードを行ったり、シャベル/くわやスタビライザーバーを使用したりすることはありません。その時点で、なぜ車を使用しないのですか？
• @TjaartASPNETページに複数のフォームを含めることができないのは正しくありません。ASPNETページには必要な数のフォームを含めることができますが、サーバーフォームは1つだけにすることができます-runat = ” server “のフォーム属性。

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

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

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

すべての回答に感謝します。

コメント

• スコットガスリーが発明しました2006/7にロンドンからシアトルに戻るフライト中のASP.NETのMVCフレームワーク。考えてみると、彼は.NETもほぼ発明しました（ en.wikipedia.org/wiki/Scott_Guthrie ）。彼を”エキスパート”と呼ぶのは、非常に控えめな表現です;-)
• その’スコットガスリーからの素晴らしい政治的回答。彼自身が自分のWebアプリケーションに投資している場合は、’ MVCプロジェクトが表示され、MVCでは’実行できなかったものがあります。 Silverlightがフォールバックになります。 ‘これをWebFormsに対する否定的なコメントと見なさないでください。WebFormsは、Telerikによって作成されたサードパーティコンポーネントなどのサードパーティコンポーネントの恩恵を受けることができる、スコープの小さい内部アプリケーションに最適だと思います。 ‘ Microsoftが両方のテクノロジを前進させてくれてうれしいです。
• ” ScottGuthrieがASP用のMVCフレームワークを発明しました飛行中の.NET “これはMVCを非常に簡単にすると思います。 ‘スコットガスリーを知りませんが、’彼がASP.NETでMVCを実装する方法を推測していたことは間違いありません。しばらくの間、その長いフライトを使用して、概念実証としてベアボーンプロトタイプを実装しました。
• “そのため、両方に投資しています。”そして、Webフォームが減少し始めた場合、最終的に死んだ製品への投資は私たちの最善のビジネス上の利益ではないため、容赦なくドロップします。
• それはもはや学校で教えられていません、何年もの間、それはビジネスの世界で常に適用可能です。大学や高校は、vb.netで引き続き入門コースと上級コースを提供しています。どこにも行きません!!!

これは多くの回答がある古い質問ですが、回答はありません

簡単な答えは次のとおりです。

• 最新のプログラミングを使用してWebアプリケーションを適切に構築する場合は、ASP.NETMVCを使用してください。 ASP.NETプラットフォームの規則と業界で採用されているパターン。欠点としては、HTMLとクライアント側のリソース（Javascript、CSS）がどのように機能するかを理解し、学習曲線が急であるが把握すると突然終了するMVCプログラミングの考え方を強化することが期待されます。
• GUI 中心の RAD（Rapid Application Development）、ドラッグアンドドロップで何かを非常に迅速にプロトタイピングするアプローチ。つまり、プッシュボタン/データグリッドの動作が15分以内に配線され、ソリューションはによってサポートされるものを意図していません。開発者。または GUI またはWindowsフォーム開発のバックグラウンドがあり、転送したい場合は、ASP.NETWebフォームを使用します。 Webに関する知識。

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

ASP.NETWebフォームはMicrosoftの回答でした。 Visual Basic 6Acを使用して動的なWebアプリケーションを構築していた人tiveXコントロール、サーバー上のVB6 DLL、およびASPクラシック。当時、これらのMicrosoftツールを使用したWeb開発は非常に混乱していました。マイクロソフトの出力である.NETFramework全体に加えて、Windowsスタックで生産的なビジネスプログラミングを行う方法について基本的に設計図に戻り、ASP.NETWebフォームは当時は素晴らしく美しいものでした。

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

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

これは2002年のテクノロジーでした。当時、インターネットへの回答として驚くほど美しく – RAD 開発用の GUI ソリューションを有効にしました。達成する必要のあるビジネス目標を持っていたソフトウェア開発者の乱雑な世界に。

残念ながら、このプログラミングモデルは、Windows GUIプログラミングの比喩を非常に強調しているため、必要な実装の詳細の負担を伴います。 、すべての厄介な手荷物necイベントのライフサイクルに対応し、これらのドラッグアンドドロップコンポーネントとコントロールが出力する単純なHTMLとスクリプトの醜い詳細を隠すために不可欠です。そして、結局のところ、実際のアプリケーションをサポートする開発者は、必然的にこれらのコンポーネントを深く掘り下げるか、独自に作成する必要があり、その結果、このインフラストラクチャとの戦い、がらくたの山に山を残す戦い、引っ張られた髪、涙。

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

Webアプリケーションを構築および管理する必要があります。私たちの制約は、ワールドワイドウェブがあることです。これはHTTP、HTML、Javascript、CSSにあり、サーバーにはビジネスルール、データベース、および少数の優れたプログラミング言語（C＃など）があります。開発方法を推進するために、このWindows GUIメタファーが本当に必要ですか？なぜ、アプリケーションの問題に焦点を合わせて、GUIの比喩を排除できないのでしょうか。

ここでASP.NETMVCが登場します。これは、適切で純粋なソフトウェア開発の原則に戻りたいと考えていた「Alt.Net」と名乗る開発者の反乱から始まりました。煩わしさや煩わしさはもうありません。ビジネス目標とソフトウェアのベストプラクティスに集中するだけです。

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

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

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

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

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

コメント

• これは良い答えですが、＃1と＃2は間違っています（WFはコンポーネントがデータの場所を知る必要がありません）から来る、それはオプションであり、レンダリングしているaspタグをサポートするために常にASPXファイルにHTMLを追加しています。開発者向けではないASP機能にアクセスしようとしない限り、深く掘り下げてコントロールと戦う必要はありません。相互作用。重要な点は、テスト容易性と設計パターンです。）

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

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

MVC
本当に自分でロールしたい場合で、アプリケーションを最初から開始する機会がある場合に使用します。明確に定義されたMVCアプリケーションを用意することは、始めるのに少し手間がかかりますが、保守性におけるその利点は、初期セットアップコストを上回ります。興味深いAjaxインタラクションを実行したい場合、クリーンURLやルートなどのコードを使用してモデルを記述し、アプリのフロー全体を制御できるようにする場合は、これが間違いなく進むべき道です。ある程度の慣れが必要です。最初はそうですが、グリーンフィールドアプリにはより良いオプションだと思います。

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

コメント

• +1で、”の両面を再生して配信される素敵な写真気の利いたコードビハインドファイルからのフェンス”。
• これは非常に役立ちます。私は’非常に重いグリッドベースのアプリを実行していて、’はsilverlight、xbapを除外しましたが、それはこれら2つ。

私の経験：

• CakePHPプロジェクトを作成しました1年間。
• 6か月で中規模のWebformsプロジェクトを完了しました。
• 3年間WindowsFormsプロジェクトに取り組みました。

後その経験から、Webフォームを使用して別のアプリを作成しようとしましたが、Webフォームが開発者を「html、javascript、cssを使用するアプリケーションを開発している」という現実から保護しようとする方法に約1日苦労した後、イライラしました。

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

jQueryのような強力なUIフレームワークの可用性かさばるビルド済みのUIコンポーネントを使用することを優先して、出力の直接制御を放棄する魅力を引き出します。

コメント

• @ JimG-うーん、興味深い関連付けなしでレコードをデータベースに入力し、その人または他の誰かに他の時点でレコードを読み取らせたり印刷させたりすることを含むものはすべて、基本的にMVCフレームワークを使用して足場を組むことができます。確かに、それはほとんどのアプリでは’ではありませんが、’はFormsでできるよりもはるかに多くのことです。あなたの-1が私の主張を証明していると思います。
• その’は1日の1/4です。
• ただし、要件が” 2つの役割を持つアプリが必要です。1つは情報を記録するためのもので、もう1つはそれを確認するためのものですが、’実際にはありません。 “そうです、そうです、’はかなり実行可能です。
• 申し訳ありませんが、データを入力してデータを表示するWebフォームアプリの開発は非常に簡単なので、数時間で完了できます。 MVCアプリ、コントローラー、ビュー、アクションの構造を作成するのに同じ時間がかかりますが、完成品に到達することはできません。
• @Dementic通常、単純なMVCアプリの場合、モデルを構築してから、スキャフォールドコントローラーとビューを作成したり、スキャフォールドコントローラー/ビューを生成したりします。そこには本当に時間のかかるものはありません。

私のバックグラウンドはWindows開発であるため、Webフォームが好きです。

開発の速度は重要な問題であり、フォームを使用して一晩で修正するために、インドの誰かに問題を簡単に渡すことができます。また、ページに速度の問題がある場合は、asp.netに関する非常に優れた本です。速度は便利です（Rick Kiessigが男性です）。

webformsは元のWindowsユーザー向けですmvcはWebユーザー向けです

しかし、Rickが素晴らしい本を書いた現代の世界では、サーバーの速度が毎日向上し、インドでは安価なコーダーが使用されているため、Webフォームには優位性があります

私の2セントはオプションがある場合は、新しいプロジェクトに常にASP.NETMVCを使用します。私の意見では、WebフォームはWebアプリを開発するための良い方法ではありません。

基本的なRESTを抽象化することは悪いことであり、ポストバックモデル全体が悪いことであり、html / cssが信頼できる方法であると思います。 GUIエディターの機能が悪い、ウィザードやGUIなどの設定に重点が置かれている、URLが悪い。

コメント

• なぜそう思うのか、詳しく説明していただけますか？
• 基本的なRESTの抽象化が復活し、ポストバックモデル全体が復活し、GUIエディターに依存してhtml / cssを処理する方法が悪いと思います。 、設定のためのウィザードやGUIなどの強調が悪い、URLが悪いなど

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

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

それまでずっと、私は最近までWebプロジェクトに取り組んでおらず、WPFを使用してWindowsアプリケーションを構築していました。

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

つまり、2つで私が見つけた主な違いは次のとおりです：-

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

• 他のテクノロジーのWeb開発から来た人にとっては、MVCはそれを嘲笑するので好まれますそれらすべての最新のもの。

• HTMLとCSSの十分な知識があれば、MVCでの開発はより簡単でクリーンです

• 展開はまだ問題です。 Webフォームでは、コピーアンドペーストを行う必要があります。ただし、これにはいくつかの作業が必要です。

要するに、どちらもしばらくここにとどまります。

このスレッドに対する既存の15の回答の中で、この考慮事項が提示されているのはまだ見ていませんが、私はそう思います「検討する価値があります。

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

他の回答が指摘しているように、MVCフレームワークでの開発はRubyでのWeb開発に似ています。 PHP、PythonなどのMicrosoftの対応物よりも;したがって、当然、MVCの選択は、他の回答で提出された要因とともに、それらの領域でのチームの経験によって影響を受ける可能性があります。

コメント

• + 1確かにWebformsの合理的な議論。私の恐れは、チームが新しいことを学ぶことを避けるためにこの考え方に従うことです。 MVCには、チームにはなじみのない多くのパターンがあります。これらのタイプのパターンを学習して実装することで、SOLIDの原則をより適切に順守し、全体的な保守性を向上させることができます。これらの実証済みの手法は、再利用性の真の鍵でもあります。

参加しない理由数年前のMVCにとって、それはMicrosoftの未熟なテクノロジーでした。過去数年間で、私たちはより成熟したバージョン（4）を使用しており、MSはこれをどこに進めているかを理解しているようです。ただし、バージョン4で使用する機能にはWindows 2012サーバー（IIS8経由のWebソケット）が必要なため、MVCを使用した主要なLOBアプリの開発にはまだ消極的です。より多くのサードパーティのコントロールが利用可能になり、テクノロジーが定着し、それをサポートするインフラストラクチャが整うことを願って、あと1年でMVCの受け入れが増えると思います。

コメント

• Windows Server 2012が必要だと言うこれらの機能のいくつかをリストしていただけませんか？

この決定は、好み、要件、さらには知識と経験によって異なります。

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

一方が他方より優れているというわけではありません。単に、アプローチまたはフレームワークの両方に長所と短所があります。

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

よろしく

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

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

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

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

WebFormsで見つかった唯一の制限は、依存性注入/反転を使用する場合です。コントロール、WebFormsページにはパラメーターなしのコンストラクターが必要なため、コンストラクターインジェクションを使用できません。したがって、プロパティインジェクションを使用する必要があります。これは本当に大したことですか？

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

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

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

本質的に、違いは、データを表示するための処理のはるかに多く（通常はすべて）があることです。ビューファイルに移動し、ビジネスロジックと残りの部分をコントローラーに残して、慣例により両方をクリーンに保ちますが、Webフォームで許可されているよりも相互にアクセスしにくくします。

コメント

• では、MVCよりもWebフォームを優先する必要があるのはいつですか。これは、元の投稿者の質問には答えません。
• @ WeekendWarrior-クライアントへのサーバー側のアクセスを増やしたい場合は、Webフォームを選択します。コード内のクライアント/サーバーをさらに分離する必要がある場合は、MVCを選択します。結局のところ、どちらもまったく同じことをします。再ルーティングフィルターはMVCURLと同じことを行い、Webフォームコードを別の中間層に移動して、さらに分離することができます。 weblogs.asp.net/scottgu/archive/2010/01/24/ …
• 3番目のポイントに関しては、そのビジネスロジックは最終的に.aspx.csファイルになります-これは開発者の責任だと思います。 ‘は/想定/されていません。 Webフォームでは、.aspxは” view “であり、.aspx.csは” controller “と同等で、ビジネスレイヤーまたは粗粒度のビジネスファサードレイヤーをポーリングすることにより、UIのみに直接関連するコードを処理することを目的としています。人々がビジネスロジックを.aspx.csに配置しているという事実は、プログラミングが不十分です。また、MVCのビューにビジネスロジックを正しく配置することもできます。 MVCは’これらのものの分離を強制しません。
• 本質的に、彼はここに投稿された他の回答よりも正しいです。 ASP.netは、Microsoftによって作成されたモジュラーWebテクノロジファミリの背後にある基本的な考え方です。 ASP.net MVCモジュールは一時的な誇大宣伝かもしれませんが、それが最後ではないことは確かです。すべてASP.netで始まるので、ASP.netを選択するとき、MVCが自分のものではないと思われる場合は、おそらくもっと何かに興味があります。それ以外の場合は、OWINまたは…、より高度なもの、またはタスク用の独自のフレームワークを作成しました。 ASP.MVCは必要ないかもしれませんが、スキップしてOwinまたはKatanaに移動しますが、そこまではaspを使用します。net

私の意見では、これらは十分に関連しており、本来あるべき機能とほぼ同じです。

優れたWebForms開発者は、優れたMVC開発者と同等に強力な製品を作成できます。しかし、MVCを採用するように強制しようとしている優れたWebForms開発者は不足するでしょう。 WebFormsを試してみる優れたMVC開発者にも同じことが言えます。

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

これは、使用するテクノロジーに精通していることを前提とした、個人的な選択に関するものです。私は長年WebFormsの設計アプローチを使用してきましたが、唯一の欠点は、その単純なアプローチのために、多くの人が時間をかけてその膨大な機能を発掘しないことです。

最近MVCを使用してプロジェクトを完了しました。アプリケーション開発の設計アプローチ（より詳細な制御、クリーンURL、SOCなど）は非常に気に入っていますが、実際にはそれほど多くはありません。 、そのWebFormsはできません。実際、jQueryの登場とWebForms（およびMVC）との連携により、これらの議論はそれほど問題になりませんでした。MVCがMVPよりも優れている点として関心の分離について話すとき、私は彼らにどれだけ質問しますか。彼らはオブジェクト指向プログラミングと、抽象化と多態性の原則をどれだけ活用しているかを知っています。

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

コメント

• 同上Webフォームの広大な機能。ほとんどの人はWebフォームのトレーニングホイールを見て、これをMVCと比較しています。
• この時代では、HTMLとJavascriptに加えて抽象化を学ぶことにはほとんど意味がありません。 2013）。’将来の機会に役立たないでしょう。HTMLとJavaクリプトはそのままで大丈夫です。それと戦うことは敗戦です。

プログラミングの問題に直面したとき、私はよくWebに目を向けます。答えのために。 Webformsには、ほぼすべてのことを行うための情報/コンポーネントがたくさんあります。 MVCでは、オンラインのソースが少なく、何かを機能させるために必要な抽象化レイヤーが原因で、かつてできることには限界がありました。 MVCトータルは、開発者としての私の生産性を損ないますが、Webフォームではそうではありません。したがって、今のところ、MVCがWebフォームを置き換えるのに十分成熟するまで、Webフォームに固執しています。

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

上級/経験豊富なプログラマーは年をとっていて、彼らが彼らより長くプログラミングしたという事実のために古いテクノロジーに習熟するでしょう。

WebFormsアプリケーションと同じようにMVCに習熟するためにお金と労力を費やすことができない限り、間違いなく、新しいものへのアップグレードを延期することになります。プラットフォームを可能な限り長くします。

したがって、いくつかのロジスティック上の問題が発生します。MVCの利点は、品質の低下という点でコストを上回りますか。展開時間？完全にWebFormsで記述されたサイトがある場合、MVCをそのサイトに統合することは労力とお金の価値がありますか？

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

これら2つのテクノロジーのギャップは、以前ほど広くはないと思います。

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

質問に直接答えるには、好みに応じると思います。および/またはプロジェクトとは何か。どちらも、開発に対して大幅に異なるアプローチを採用しています。個人的にはMVCへの移行に取り組んできましたが、それでもWebformsでの作業を楽しんでいます。MVCとWebformsのどちらを使用すべきかについての答えは、両方のテクノロジーを体験して決定することだと思います。

コメント

• WebフォームとMVCは、デフォルトで根本的に異なるWeb開発態度を推奨しています。これは重要であり、逸脱する開発者はほとんどいません。 “デフォルトの”から。 ただし、どちらも同じことを実現するために使用できます。