4

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

私は2つを混在させることについてすべての調査を行い、MVCルートを使用するプロジェクトをすべてセットアップしArea、残りの（ビジュアルスタジオ）プロジェクトは実行中の方法でWebフォームで実行しました.

マスター ページは Razor レイアウトに変換されましたが、すべてのアプリケーション間で共有されるマスター ページが 1 つしかなかったため、それほど悪くはありませんでした。

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

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

私の直感では、本当に良い解決策はなく、このプロジェクトで MVC に移行するという考えを放棄し、Web フォームに固執する必要があるかもしれませんが、SO コミュニティがこのシナリオで何をすべきかについて洞察を持っているかどうかを確認したかったのです。 .

4

1 に答える 1

4

MVC パラダイムを使用してこれらのサーバー側のコントロールを書き直す予算がある場合は、それが最善の方法です。そうでない場合でも、それらを既存の従来の WebForms ページに埋め込むことができ、標準の HTTP/HTML 手法を使用して新しい MVC アプリケーションと通信することができます: フォームの投稿、クエリ文字列パラメーターによる ID の送信、iframe、Cookie、HTML 5 ストレージなど.ただし、サーバー側のコントロールを MVC ビューに配置しないようにしてください。最終的には、適切な ASP.NET MVC でも適切な WebForms でもないハイブリッド アプリケーションができあがります。

個人的には、この同じ移行を複数回行う必要がありましたが、Areas やその他の手法を使用して、同じアプリケーションで従来の WebForms と MVC を混在させる必要はありませんでした。結局のところ、この 2 つを一緒に存在させようとするのは悪夢に変わるかもしれません。それは常に 2 つのうちのいずれかです。予算があり、ゼロから適切に書き直すか、予算がなく、ASP.NET MVC を使用して新しいことを適切に行い、既存のアプリケーションとやり取りしようとします。

探している相互作用に応じて、既存の WebForms アプリケーションから機能を統合するためのさまざまな方法を使用する別の MVC アプリケーションを単純に開始する方が簡単だと思います。

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

于 2011-08-07T17:02:44.923 に答える