winform とクライアント アプリケーションの経験がある人として、従来の ASP .NET ページの動作方法に戻って学習する価値はありますか、それとも ASP .NET MVC に直接移行しても問題ありませんか?
私は一般的な C# に関する知識の落とし穴や落とし穴を探しています。スクリーンキャスト シリーズや ASP .NET サイトの情報からはわからないものです。
winform とクライアント アプリケーションの経験がある人として、従来の ASP .NET ページの動作方法に戻って学習する価値はありますか、それとも ASP .NET MVC に直接移行しても問題ありませんか?
私は一般的な C# に関する知識の落とし穴や落とし穴を探しています。スクリーンキャスト シリーズや ASP .NET サイトの情報からはわからないものです。
ここにMVCの素晴らしいところがあります。これは、通常の ASP.NET Web フォームよりもフレームワークのベースに近く動作します。したがって、MVC を使用して理解することで、Web フォームのしくみをよりよく理解できるようになります。WebForms の問題点は、多くの魔法があり、Web を Windows Forms のように機能させるために約 6 年を費やしたため、コントロール ツリーの階層とすべてが Web に変換されていることです。MVC を使用すると、WinForm の影響を受けずにコアを取得できます。
したがって、MVC から始めれば、必要に応じて WebForms に簡単に移行できます。
Nickに同意します。MVCは実際のWebパラダイムにはるかに近く、それを使用することで、Webサイトが実際にどのように機能するかに直面することになります。WebFormsは、これらのほとんどをあなたから引き離します。PHPのバックグラウンドから来ているので、私はそれが本当に直感に反していることに気づきました。
MVCに直接ジャンプして、WebFormsをスキップすることをお勧めします。すでに述べたように、必要に応じて元に戻すことができます。
ASP.Net Webforms は、基本フレームワークに対する ASP.NET MVC とはまったく異なる抽象化です。MVC を使用すると、ASP.NET Web フォームよりも内部で何が起こっているかをより詳細に制御できます。
私の意見では、物事を行うためのさまざまな方法を学ぶことで、通常はより優れたプログラマーになることができますが、この場合は、学ぶべきより良いことがあるかもしれません.
ASP.NET MVCは、クライアントコードをサーバーコードから分離したい開発者向けです。サーバー間を移動できるJavaScript、XHTML、CSSクライアントを作成したいと思っていました(サーバーテクノロジーに関係なく)。クライアントは、適合と完成に時間がかかるため、できるだけ多くのサーバーでクライアント(およびサブコンポーネント)を使用することをお勧めします。また、このデカップリングにより、サーバーは、HTTPおよびWPF / Silverlightなどのアングルブラケット(および/またはJSON)をサポートするすべてのクライアントテクノロジをサポートできます。ASP.NET MVCがないと、ASP.NETチーム全体と敵対的な関係に陥ることになります---しかし、Scott Guthrieはクールな人物であり、彼の前任者(そしておそらくScott自身)がほぼ完全に焦点を合わせた後、MVCをテーブルにもたらしますWindowsフォームプログラマーにWebアプリケーションを作成させる。
ASP.NET MVCの前は、主にASHXファイル---HTTPハンドラーに基づいてASP.NETアプリケーションを構築していました。「本物の」マイクロソフトショップがこの振る舞いを奨励することはないでしょう。(賢明な)管理の観点から、すべての開発者がベンダーのツールを使用するベンダー推奨の方法を使用するように指示する方が簡単です。したがって、1〜2年遅れているITショップでは、MVC以前の方法を知っている必要があります。これは、維持する「レガシー」システムがある場合にも役立ちます。
しかし、グリーンフィールドの場合、それはずっとMVCです!
それはあなたのモチベーションに依存します。ASP.NET開発者として自分を売り込む場合は、両方が必要になります。
これがあなた自身の喜びのためだけである場合は、MVCにアクセスしてください。
私の個人的な感想は、ウェブフォームはもう数年は存在するだろうということです。非常に多くの人々が彼らに時間とエネルギーを投資しています。ただし、人々はゆっくりと(またはそれほどゆっくりではないかもしれませんが)移行すると思います。Webformsは常に、ドラッグアンドドロップのVB4モルトにWeb開発について考えさせるための単なる方法でした。それはちょっとうまくいきましたが、それは多くの制御を奪います。
これまでは従来のモデルしか使用していなかったため、MVCと「従来型」について技術的に話すことはできません。しかし、私が読んだことから、一方が他方よりもはるかに優れているとは思いません。一度「理解」すれば、両方で非常に生産的になることができると思います。
ただし、実際には、ほとんどの本、コードサンプル、および既存のアプリケーションは「従来の」方法で作成されていることを考慮に入れます。あなたはより多くの助けを利用でき、あなたのスキルは「伝統的な」方法で書かれた既存のアプリケーションを持つ雇用者にとってより役立つでしょう。
IMO、通常の Web フォーム シナリオには、MVC だけよりも多くの落とし穴があります。Viewstate とデータ バインディングは、扱いにくい場合があります。
しかし、MVC の場合、昔ながらの単純な方法でポスト/レンダリングするだけです。それが悪いというわけではありません。ただ違うだけで、よりクリーンでもあります。
生レベルの Web 要求/応答および生の html/css レンダリングの方法がわからない、または経験がない場合は、MVC を開始するのに適しています。これにより、Web フォームと MVC の両方の長所と短所をよりよく理解できるようになります。どちらも異なるニーズに対応するため、将来的にはどちらも存在するでしょう。
Webフォームは非常に悪用され、悪用されているプラットフォームだと言います. 「コードを見てはいけない」ゴミの多くは、それを使用するすべての人に悪い名前を付けます. 時間をかけて理解して適切に使用すると、非常に拡張性が高く堅牢なプラットフォームであることがわかります。