従来のASP .NET WebフォームとMVC

Question

いくつかのwinformsとクライアントアプリケーションを経験した人は、従来のASP .NETページの動作方法を学ぶか、ASP .NET MVCに直接移行するのは大丈夫ですか？

私は一般的なC＃についての私の知識の中で落とし穴やトラップを探していますが、スクリーンキャストシリーズやASP .NETサイトのことはわかりません。

Answer 1

ここではMVCの素晴らしい点があります。これは、通常のASP.NET Webフォームよりもフレームワークのベースに近い動作をします。 MVCを使用して理解することで、WebFormsの仕組みをよりよく理解することができます。 WebFormsの問題は、多くの魔法があり、WindowsフォームのようにWebを動作させるために約6年を費やしているため、コントロールツリー階層とすべてのものをWebに変換したということです。 MVCを使用すると、WinFormの影響を受けずにコアを得ることができます。

MVCを使い始めると、必要に応じてWebFormsに簡単に移動できます。

Answer 2

ASP.Net Webformsは、ASP.NET MVCとは基本フレームワークとは全く異なる抽象化です。 MVCを使用すると、ASP.NET Webformよりもカバーの下で何が起こるかをより詳細に制御できます。

私の意見では、物事を行うさまざまな方法を学ぶことは、通常、より良いプログラマーになるでしょうが、この場合、もっと良いことがあるかもしれません。

Answer 3

IMOでは、通常のWebフォームのシナリオでは、MVCだけでなく、より多くの落とし穴があります。ビューステートとデータバインディングは時々難しいことがあります。

しかし、MVCの場合、これは単なる単純なフォーム投稿/レンダリングの古い学校の方法です。それは悪いことではなく、ただ違っていて清潔です。

Answer 4

これまでの伝統的なモデルを使用していたので、私はMVCと伝統的に技術的には話せません。私が読んだことから、私は誰かが他の人よりもはるかに優れているとは思わない。私は一度あなたが "それを得る"と思う、あなたは両方で非常に生産的になることができます。

実際には、私は、ほとんどの書籍、コードサンプル、そこにある既存のアプリケーションが「伝統的」な方法で書かれていることを考慮します。より多くのヘルプがあり、あなたのスキルは、「伝統的な」方法で書かれた既存のアプリケーションを持つ雇用主にとってより有用になります。

Answer 5

私はニックに同意します：MVCはリアルウェブパラダイムに非常に近いので、あなたのウェブサイトが実際にどのように動作するかに直面します。 WebFormsはあなたから離れたこれらの事柄のほとんどを抽象化し、PHPのバックグラウンドから来て、私はそれが本当に反直感的であることを発見しました。

MVCに直接ジャンプしてWebフォームをスキップすることをお勧めします。言われたように、あなたは必要に応じてそれに戻ることができるでしょう。

Answer 6

あなたの動機によって異なります。あなたがASP.NET開発者としてあなた自身を売却するつもりなら、あなたは両方を必要とします。

これはあなた自身の喜びのためのものであれば、MVCに行ってください。

私の個人的な気持ちは、Webフォームがかなりの数年前から存在するということです。多くの人が時間とエネルギーを投資しています。しかし、私は人々がゆっくり（あるいはゆっくりではないかもしれないが）移住するだろうと思う。 Webformsは、ドラッグアンドドロップVB4モートがWeb開発について考えるようにする単なる方法でした。それは働いたが、それは制御の多くを取り除く。

Answer 7

生のレベルのWebリクエスト/レスポンスと生のhtml/cssレンダリングをどのように経験していないのかわからない場合は、MVCを開始するのがよいでしょう。 これで、webformsとmvcの長所と短所をよりよく理解できます。両者は異なるニーズに対応しているため、今後も両方とも周辺にあります。

私はwebformsは非常に悪用され、悪用されたプラットフォームだと言いますが。 "look no code"のゴミは、誰もそれを悪用するものです。 これを理解し、正しく使用するためには、非常に拡張性と堅牢性の高いプラットフォームが必要です。

Answer 8

ASP.NET MVCは、クライアントコードをサーバーコードから切り離したい開発者向けです。私はJavaScript、XHTML、サーバーからサーバーへ（サーバー技術に関係なく）移動できるCSSクライアントを書こうと思っていました。クライアントは時間とコストがかかり、できるだけ多くのサーバーにそれら（およびサブコンポーネント）を使用したいと考えています。また、このデカップリングにより、サーバーはWPF/SilverlightのようなHTTPおよび角括弧（および/またはJSON）をサポートするクライアントテクノロジをサポートできます。 ASP.NET MVCがなければ、ASP.NETチーム全体と敵対関係に陥ってしまったのですが、Scott Guthrieはすばらしい男です。前任者の数年（そしておそらくScott自身）のほとんどがWindows FormsプログラマーにWebアプリケーションを作成させる

ASP.NET MVCの前に、主にASHXファイル--- HTTPハンドラに基づいてASP.NETアプリケーションを構築しました。マイクロソフトの「本物の」ショップがこの行動を促すものではないことを私は保証することができます。すべての開発者がベンダーが推奨する方法でベンダーのツールを使用するよう指示するのは、（賢明な）管理の観点から簡単です。したがって、1〜2年後のITショップでは、MVC以前の方法を知る必要があります。これは、あなたが維持する "遺産"システムを持っているときにも便利です。

しかし、緑色のフィールドでは、それはMVCのすべての方法です！