なぜWebフォームでMVCを使用するのですか？

Question

最近、建築家は、必要なのはトヨタ（Webフォーム）だけで、Rolls-Royceソリューション（MVC）を提供していると私たちの会社を説明しました。

Web Forms vs MVCについてあなたがアーキテクチャの選択としてどう思うかを知りたいと思います。

Answer 1

Rolls-Royce/Toyotaの類推は、ひどく欠陥があり、誤解を招くものです。 1つ（ASP.NET MVC）は、他のasp.net Webformsのよりファンシーまたはより高価なバージョンではありません。それらは、ASP.NETを使用してWebアプリケーションを構築するための非常に異なるアプローチです。

私にとって、MVCとWebformsの最大のアーキテクチャの違いは、WebのStateless Environmentを使用する方法です。WebFormsは、Webプログラミングのステートレス性を隠す一連の抽象化を構築するために一生懸命働きますが、MVCはステートレス環境を取り入れて機能します。それ。

それぞれのアプローチにはその利点と不利なものがありますが、MVCを使用してWebサイトを構築する方法がはるかに感じる方法を本当に楽しんでいます ナチュラル WebFormsよりも 漏れやすい抽象化の層の上に層).

Answer 2

古い質問ですが、他の誰かがまだ実際にジレンマを持っている場合に備えて、より詳細な答えに値します。

最終的に、WebFormsは薄クライアントソリューションであり、それによってはきれいなボタンの束を押すことを意味し、フロントエンド（クライアント）のものがあなたのために構築されます。 Webformsでそれをクランクアウトする方法を知っている人がいて、保守性/修正性の懸念がまったくなく、サイトは完全に短期的で使い捨てである場合、このアプローチにはまったく間違っていません。独自のことをする方法を学ぶことは可能ですが、この場合、両方のWebのwebformsが.NETアプリ開発者を保護しようとすることを知る必要があります。責任者。

他のすべてのユースケースシナリオの99.5％では、アプリ開発者からWebを隠そうとするのをやめました。本当に、Webアプリを書きたいなら、実際にWebの仕組みを学ぶ方がはるかに良いからです。太いクライアントソリューションと薄いクライアントソリューションの皮肉は、必然的に薄切りアプローチが必然的にフロントエンドからがらくたを膨らませ、パフォーマンス以外のものであるということです。さらに重要なことは、これらのソリューションは、自分が何をしているのかを実際に知っており、有効なフレームワークに制約されたくない人々にとって、常に物事を柔軟性のないものにしてきたことです。

CSS、JavaScript、HTML、XHRについてすべてを知っている人を連れて行くほど無意味なことはありません。

• スクリプトの依存関係を台無しにするのを防ぐために、ヘッドタグのすべての「不必要な」スクリプトタグをクリアします。 （「スクリプトマネージャー」があなたのためにそれを処理させる方が良い）認められた、彼らが何をしているのかを知っていれば、誰もそこに置いていないが、それはただ台無しになっている。

• すべてのHTMLを1つの巨大な形式のタグでラップすると主張します。 HTMLはフォーム内のフォームを許可していないため、WebFormsの方法またはまったく方法ではありません。

• ブラウザと対話してサーバーにメッセージを送信し、サーバーが応答したときに反応することにより、UIイベントに実際に反応する必要があるため、18段階の「ライフサイクル」のように作成されます。ゴミの大きな巨大な山でそのプロセスを抽象化する必要はありませんでした（そして公平を期すために、これをやろうとしたのはMSだけではありません）。

• 実際には、問題に対する非ウェブフォームソリューションを使用する邪魔になるために、可能な限りすべてを行います。例：私がよりジュニアクライアント側の開発者だったとき、私はページの上部に送信ボタンを作成する方法を見つけるために1日を費やしました（ページの下部に送信ボタンをトリガーします（その1つのビグのために想定しています。巨大な形のこと）。通常、これには5分かかりますが、かなりの数時間のエンジニアリングの後にWebForms JavaScriptの責任を負った後、私はそれらが特に私が知っていなかったプロパティを設定したものであることを発見しました。フォーカスは、送信ボタンをクリックすると、公式のMicrosoft Submit（TM）ハンドラーのアクティブ化に関して、公式Microsoft Submit（TM）ボタンのみが機能するようにしました。

いいえ、ロールスロイス対トヨタはまったく不合理です。私は、あなたがマイクロソフト以外の誰かからガスまたはオイルを購入し、検出されたときに90度のターンを自動的に90度ターンするオンボードシステムを備えたマイクロソフトエンジニアリングピントのために多額の支払いをする完全に合理的なヒュンダイをもっと言うでしょう。バタンと閉まる便利な壁。ウェブについて何も知らず、マイクロソフトへの生涯にわたる忠誠心を誓いたいと思っている自殺的にブランドの忠実なドライバーにとって理想的な車。

すべての.NET MVCは本当にシンプルで合理的であり、Webの上に平手打ちする独自のレイヤーを再発明することはありません。それはあなたのためにいくつかのボイラープレートをノックアウトするのを助けるためにそこにあるものと一緒に動作します。より良い/安価/フリーエルフレームワークが利用可能ですが、既に.NETのものに自分自身をロックしている場合は、さらに悪いことになります。

しかし、真剣に、！@＃$をWebformsから離してください。今はほとんど死んでいます。手放す。クライアントに、実際に何か新しいことや違うことをしたいとき、またはCrapが壊れ始めたときに排他的で収益性の高いサポート契約を約束する場合、あなたは3倍のお金でそれをすることを伝えます10,000行のajax.jsファイルのその巨人に追加し続けて、触れられないdll assから引き出します。

Answer 3

ASP.NET MVCソリューションは、WebFormsソリューションよりも複雑である必要はありません。個人的には、ASP.NET MVCは実際にはWebFormsよりもはるかにシンプルであると思いますが、それは間違いなく本質的にクリーンであるようです。

私の経験から、多くのMVCフレームワーク（ASP.NET、Rails、CodeIgniterなど）には、同じコア機能と規則がたくさんあります。ウェブフォームは、本当にウェブの観点から奇妙なアヒルです。私の推測では、ほとんどのWebプログラマーは、WebFormsよりもASP.NET MVCをピックアップするのがはるかに速くなると推測しています。

Answer 4

ASP.NET MVCをASP.NET WebFormsで使用する最大の理由は、テスト能力です。確かに、あなたは一種のユニットテストウェブフォームを使用できますが、これには模擬フレームワークと多くの痛みが必要です。 2番目の理由は、MVCが少し作ることです より簡単に 懸念を分離する。これにより、大量のコードの再利用が提供され、コードがゆるく結合されます。これは、MVPなどのパターンを使用してASP.NETで同じことを行うことが不可能であるという意味ではありません。

MVCの欠点は、多くの機能を失い、過去10年間（ほぼ）にウェブフォームに組み込まれていることです。 MVCは、開始以来、同様の機能を提供するために長い道のりを歩んできました。

パフォーマンスに関しては、誰もがどの技術が「より速い」かを証明していますか？

一方は他方よりも優れているとは思わない。私はMVCフレームワークが本当に好きで、大成功を収めて使用しましたが、プロジェクトに一致する技術を選択することを常に確認しています。