既存の大規模なカスタムコントロールのライブラリを持つWebFormsからMVC3への統合/切り替え

Question

ここには状況があります。私たちはWebFormsに基づいた一連のWebアプリケーションに新しいアプリケーションを追加しています。そのため、MVCを導入するのに最適な時期だと感じました。

MVCルートを使用するAreaを使用してプロジェクトをすべてセットアップしましたが、残りの（ビジュアルスタジオ）プロジェクトは実行中の方法でWebフォームで実行されます。

マスターページはすべてのアプリケーション間で共有されたマスターページが1つだけだったので、面倒ではありません。

私が今実行した問題は、ユーザーコントロールを再利用することです。私たちには数多くのカスタムユーザーコントロールがあり、その多くはかなり複雑で、すべてのアプリケーションで再利用されています。それらのほとんど（特にポートするのが難しいもの）は、ViewStateとポストバックでかなりの量を処理します。

MVCでこれらを書き直すだけであれば、ワンタイムコストは理想的ではありませんが恐ろしいものではありません。しかし、既存のアプリも維持し更新する必要があるため、全く異なるパラダイムを使用して同じ動作の2つのバージョンを維持することは、生産性を大幅に低下させることになります。

本当に良い解決策はないと言いますが、私たちはこのプロジェクトでMVCに行ってウェブフォームに固執する考えを放棄しなければならないかもしれませんが、SOコミュニティが何を洞察するかこのシナリオで行います。

Answer 1

MVCパラダイムを使用してサーバー側のコントロールを書き換える予算があれば、これが最善の方法です。そうでなければ、既存の古典的なWebFormsページに埋め込み、標準のHTTP/HTML技術を使用して新しいMVCアプリケーションと通信することができます。フォームの投稿、クエリ文字列パラメータ、iframe、cookie、HTML 5ストレージなど確かに一つのことですが、MVCビューにこれらのサーバーサイドコントロールを置かないようにしてください。適切なASP.NET MVCでも災害となる適切なWebフォームでもない、いくつかのハイブリッドアプリケーションになります。

個人的に私はこの同じマイグレーションを何回もやらなければならなかったし、Areaや他のいくつかのテクニックを使って、同じアプリケーションでMVCと古典的なWebFormsを混在させることはなかった。一日の終わりには、それが悪夢に変わって、それらの2つが一緒に存在するようになるかもしれません。それは常に2つのうちの1つです：私は予算を持っており、最初から正しく書き直すか、予算がなく、ASP.NET MVCを使って新しいものを適切に行い、既存のアプリケーションと対話しようとします。

別のMVCアプリケーションを簡単に起動する方が簡単です。私が探しているやり取りに応じて、既存のWebFormsアプリケーションと機能を統合するためのさまざまな方法を使用します。

シナリオの複雑さと詳細に精通していないので、客観的な答えを提供するのは難しいですが、既存のWebFormsサーバー側のコントロールに基づいて新しいコードを書き続け、このプロジェクトのためにも良い解決策かもしれません。 ASP.NET MVCに新しいアプリケーションを書くことは、それが最良の選択であるとは限りません。