はいの場合、いつ?また、現在のプロジェクトを移行するためのプロセスにはどのくらいの時間がかかると思いますか(その場合)。
13 に答える
ASP.NET MVCは WebForms を置き換えるものではありません。これらは異なる技術であり、異なる目的のために設計されています。
どちらか一方のみを使用し、もう一方は使用しないという包括的な声明を出すことは、各テクノロジの長所と短所を見逃しているため、非常に偏狭なアプローチです。
Microsoft は、今後両方のテクノロジに取り組んでおり、WebForms 4.0 にはかなりの数の優れた新機能が追加されています。
WebForms と ASP.NET MVC を使用しますが、現在のプロジェクトのニーズを調べて、現在の実装に適した決定を下します。
私は数ヶ月間それを使用しています。私はMVCが大好きです。利用可能な時間によっては、既存のプロジェクトを変換することは現実的ではない場合があります。私が見ているように、Web フォームは古い VB クラウド向けの Windows フォーム開発をシミュレートします。MVC はそうではないふりをしませんが、Http プロセスにより厳密に従います。
MVC に見られるいくつかの利点
1) 単体テストでテスト可能
2) Html の直接制御。私たちはウェブサイトを作成していますが、すべての HTML を制御できないことをどのように受け入れるのでしょうか?
3) ビューステート バゲージなし
4) レンダリングに時間を浪費するコントロール ツリーがない
5) フォーム投稿からのモーダルの自動バインド
6) かなりセクシーになれる
そしていくつかの欠点
1) Web コントロールはもうありません (そして、多くの豊富なサード パーティ コントロールが失われます)。
2) 開発が遅い
3) 大きな学習曲線
4) まだベータ版 (CTP は間もなく)
はい、できるだけ整然とした方法で。
MVC は、アジャイル開発のベスト プラクティスの世界に .NET を開放します。特に、懸念事項の分離、および結合/結束に関する懸念事項に対処します。また、ベンダー固有のリファレンスやコンポーネントに依存することなく、より移植性の高いソフトウェアを作成できます。
どのような PR を読んでも、間違いなくWPF と共にWebForms の後継者です。
はい、私の新しいプロジェクトでは。ただし、現在の製品版ソフトウェアは対象外です。
Web フォームよりも ASP.NET MVC を好むと仮定すると、アクティブな開発/メンテナンス中のシステムには価値があります。
それらは並行して共存できるため、アプリケーションの一部 (新しいもの、または選択された古いもの) を移行して、それがどのように機能するかを確認することができます。成功した場合は、続行します。
ただし、「オール オア ナッシング」の移行は悲惨な結果になる可能性があります。迅速なフィードバックなしに多額の投資を行うことは大きなリスクです。
WebForms はリッチ UI 用です
これらは、MVC または Webforms とまったく同じように実行できます。今から 1 年後には、リッチな MVC ベースのツールキットが登場し (技術的には、YUI や ExtJS などが好きな人には既に提供されています)、この引数は無効になります。
現在のプロジェクトを移行する
既存の WebForms プロジェクトを MVC に移行してもあまり意味がありません。あなたは何を得るつもりですか?ただし、新しいプロジェクトに MVC を使用することは、要件によっては非常に理にかなっています。
ASP.NET MVC を数か月使用していますが、Web フォームよりも好きです。ただし、既存のプロジェクトを MVC に移行するつもりはありません。私にとって、それはむしろ無意味でしょう。ただし、私の新しい ASP.NET プロジェクトはすべて、MVC を使用して開発する予定です (または使用する必要があります)。これは、MVC の方がはるかに優れた (そしてより柔軟な) フレームワークであるためです。
私はもともと WebForms が好きではなかったので、MVC を使用するようになったことは、私にとって新鮮な空気の息吹のようでした。私は常に、関心の分離を非常に好んでいました。なぜなら、私が開発するのが本当に得意なチャンク、ロジック、およびデータ アクセスに取り組むことができ、プレゼンテーション作業は、その自然な能力を持ったチームのメンバーに任せることができるからです。MVC ライブラリを使用すると、1 人がコントローラーで作業し、もう 1 人がビューで作業できるため、チームが個々のページで共同作業しやすくなると思います。
そうは言っても、コーディングにそれほど集中する必要がなく、より表示指向のプロジェクトに取り組んでいるときは、実装と起動がはるかに簡単なため、Webフォームに戻ります。そして走っています。どちらにもそれぞれの場所があり、一方が他方に取って代わることはないと思います。
個人的には、軽量のフロントオフィスWebサイト用にASP.NETMVCを制限しました。
ただし、RighBackOfficeアプリケーションにASP.NETWebFormsを使用して、豊富なカスタムコントロールやその他のWebフォームの優れた機能を利用できます。
mvc のもう 1 つの利点は、jquery のような javascript の実装がはるかに簡単であることです。そのため、大量の js を使用する予定がある場合は、mvc を使用することをお勧めします。
すでに述べたように、それらは相互に排他的ではなく、両方をうまく利用するためにプレイしています.
IMO MVC は Webサイトに適していますが、WebForms は Webアプリケーションに適しています。
たとえば、このサイトは、サイトの性質と達成する必要があることから、ASP.NET MVC が適切な選択であることを示す完璧なショーケースです。他の良い例は、Web ストア、プロジェクト管理サイト (Basecamp など)、またはソーシャル ネットワークです。
ただし、企業の CRM/ERP システムを開発している場合、CRM アプリケーションは伝統的にデスクトップ アプリケーションのドメインであるため、豊富なコントロールとより「デスクトップに似た」プログラミング モデルを得るために WebForms を使用します。
いいえ、理由はありません。これは別のスタイルで、私は好きではありません。しかし、それは私の意見です。多くの人が気に入っており、うまくいくことを願っています。
ASP.NET MVC は、私の希望する開発スタイルにより適していますが、RTM でない限り、自分自身を信頼することには慎重です。また、従来のコードが機能しないほど大きく異なります。ドメイン駆動開発を実践していれば、もっと簡単だったかもしれませんが...