WebフォームとASP.NET MVCを組み合わせる
非常に大規模なASP.NET Webフォームプロジェクトに取り組んでいます。私たちのチームは、このプロジェクトをASP.NET MVCとドメイン主導の設計で書き換えたいと考えています。 WebフォームとMVCを組み合わせるのは良い考えですか？
このアイデアにより、すべてのページを開発し、現在のプロジェクトで新しく開発されたページを使用できます。すべてのページが書き直されるまで、古いページはWebフォームで動作し、新しいページはMVCおよびドメイン主導のデザインで動作します。
同じプロジェクトでこの2つを使用することは可能ですが、書き換えの目的で使用しないことをお勧めします。
代わりに、すべての着信トラフィックを処理して古い実装に転送するか、書き換えのステータスに応じて新しい実装に転送するファサードを構築します。
これにより、いくつかの利点が得られます。新しいプロジェクトから作業することができます。つまり、自分が最善だと感じる方法を構築できるようになります。同時に、保持したいコードをコピーできます。さらに、新しい実装に欠陥がある場合は、簡単に古いシステムに戻すことができます。さらに一歩進めたい場合は、両方のシステムを同時に呼び出すこともできます。リクエスターは実証済みの実装で提供されますが、内部的には両方を保持し、結果を比較します。新しいシステムの応答に十分満足したら、これらのタイプの要求に切り替えます。
WebフォームからMVCに移行しようとしていた製品でこれを以前に行ったことがあり、かなりうまく機能していることがわかりました。私の経験からのいくつかのメモ：
私は このブログ投稿 の手法を使用して、Razorビューで既存のマスターページを使用しました。私は2つのレイアウトを維持する必要がないようにしたかったのですが、後から考えるとこれは間違いであり、2つのレイアウトを維持することはより良い解決策ではありませんでした。問題は、Webフォームの概念がMVCページに「漏れ」続けることでした。たとえば、マスターページでスクリプトマネージャーが使用されていたため、「MVCの方法」を実行しようとすると複雑になりました。
Webフォーム固有のUIライブラリを使用したため、一部のUI要素のルックアンドフィールがわずかに一貫していませんでした。
Owin APIとWebフォームAPIが期待どおりに対話しない、Cookieに何らかの問題があったことを覚えているようです。申し訳ありませんが、詳細を思い出せません。1日ほど悩まされただけです。
注目に値するのは、Webフォームを取り除くことができなかったことです。完全に書き直す時間はありませんでした。これが最善の方法であったかどうかはわかりませんが、それも後悔した決定ではありません。