クラシックASPからASP.netまたはASP.net MVC

古典的なASPで開発されたWebアプリケーションがあり、5年間で100ページの巨大なデータベースと毎日少なくとも10ページ以上を通過する10000人以上のアクティブユーザーを含む現在の形式に進化しました。

ここで、最新バージョンの.netにアップグレードしたいと考えました。最初はアプリ全体を書き直すことを考えていましたが、シナリオを分析した後、多くの専門家によって提案されていない実行可能なオプションではないことがわかりました。他の方法でそれを行う方法についてはまだ決定していませんが、顔の書き換えを達成する方法についていくつかの考えを持っています。

オプション1： このアプリケーションのメインモジュールを識別し、データベース（既存）、ビジネスロジック、ビューなどの異なるレイヤーにアプリケーションを分離することで、それらを1つずつ書き換えることを考えました。これにより、新しく開発されたモジュールが既存のシステムに追加され、特定のモジュールの古いページが新しいページに置き換えられます。同時に、古いシステムと一緒に新しいレイヤーをテストし、自信が持てたらリリースします。また、ビジネスロジック用のAPIのような構造を開発することも考えました。これは、外部アプリケーションとしてビューによってアクセスされます。

オプション2： 現時点では、単純なモジュールを作成し、IFrameを介して従来のASPページで使用していますが、従来のASPとIFrameの新しいページとの間でデータを送信するのは非常に面倒でした。

これは、ユーザーベースに影響を与えずにアプリケーション全体を書き換える方法を計画している段階です。

そのようなシナリオでアプローチすべきかどうかについて、他のプログラマーの意見、意見、提案を取得したいですか？誰かがこの種のシナリオに直面した場合、あなたの意見も共有してください。

また、ASP.net MVCの使用がこれに役立つことを知りたいですか？

更新：あなたの意見を述べるための両方の答えをありがとう。アプリケーションを従来のaspからasp.netまたはasp.net mvcに移行する際に、上記で指定した両方のオプションでより多くの入力を取得したいです。asp.netまたはasp.net mvcを選択するという点ではなく、移行の部分についての意見、ポイント、および考えをすべて理解できれば、私にとって大きな助けになります。

「あなたの痛みを感じます、ブルサ」と言って始めましょう。私はこれを3年前に経験しましたが、その時点でMVCが成熟したことを望みます。私が設計したWebFormsソリューションは、実際にMicrosoftライブラリを構築しなくてもMVCモデルに似ているからです（もちろん、違いました）

また、iFrameを使用して、親アプリケーションとして.Netを使用し、スレーブとして従来のaspを使用してコンテンツの違いを管理することになりました。.Netでフレームワークアーキテクチャを開発し、それを実装しました。クラシックASPページは、その後、不要なプレゼンテーションピース（インクルードなど）を「選別」され、iFrameにロードされました。次に、カスタム暗号化を使用して、URLからデータが渡されました。認証が簡単にスプーフィングされないようにし、クエリ文字列を解読してページにアクセスできるようにするため、従来のASPページを解析する前に.Netに認証を強制するIISのワイルドカードハンドラーも使用しました。

それを考えると、私の推奨事項はすぐにMVCに向かうことです。

1. MVCはglobal.asaxレベルでルーティングにアクセスできるようにします。コントローラーを巧妙に操作することで、適切な方法でモデルを開発し、必要に応じてすべての従来のASP要求を処理する共通コントローラーを使用できます。
2. MVCを使用すると、テストプロジェクトの追加が非常に簡単になり、新しいモデル構造に基づいて個々のアプリケーションをリファクタリングしながら、十分なテストカバレッジを提供して、問題がないことを確認できます。リファクタリングコードのカバレッジは大きな懸念事項であるため、この値は絶対に計算できません。
3. MVCは、WebFormsよりもスクリプト化されたプレゼンテーション方法を採用しています。WebFormsは、ある種のステートフルアプリケーション（そうではない）のようにすべてを混ぜ合わせようとします。これは、従来のASPに慣れている人々にとってはカルチャーショックになる可能性があります。誤解しないでください、あなたの開発者はどの方向に行ってもカルチャーショックを受けるでしょうが、プレゼンテーション層からそのショックの一部を取り除くことができれば、あなたはより大きな成功を見つけるかもしれません。

私はWebFormsとMVCの両方が好きです（Razorの導入で認めますが、MVCに少し偏見が生じています）。両方とも場所があり、特にリファクタリングされたアプリケーションを展開する際に採用する必要がある「互い違い」な性質を考えると、説明したようなアプリケーションはMVC実装に理想的に適していると思います。

どちらにしても、認証/承認/ルーティング/などに関しては、.Netアプリケーションが常に親アプリケーションであることを確認する必要があると思います。私の同僚は、親としてクラシックaspを使用して同様のアプリケーションに移行を実装しましたが、最終的にすべてを統合することになると、多くの問題が発生しました。

ASP.NET MVCに移行しても、移行が必ずしも簡単になるとは限りません。実際、移行がより難しくなる可能性があります。ただし、すでにこの大事業を行うことを選択している場合は、時間をかけて計画に最適なプラットフォームに移行してみませんか？

ASP.NET（sans MVC）への移行は、多くのエキゾチックなことをしていない限り、大規模なリファクタリングを行わなくても既存のロジックをそのまま移植できるという意味で「簡単」になります。クラシックASP。結果は満足のいくものであり、すでにアプリケーションに精通している人には比較的なじみがあります。従来のASPからASP.NETに移植されたすべてのアプリケーションがメリットを受けるという意味で、メリットが得られます。

ASP.NET MVCへの移行はさらに作業が必要になります。MVCパターンに収まるようにアプリケーションモデルを再構築する必要があります。これは通常、懸念事項の分離などの適切な動作を促進するため、Good Thing（tm）です。結果として生じるアプリケーションは、コアロジックの部分を除いて、既存のものとほとんど同じではありません。あなたは買ってあげるだけでなく、他の利点を。それは大きな文化的変化であり、「MVCの書き方」を適切に理解するには開発チームの（再）教育が必要です。

注目すべき点として、Microsoftは ScottGuによるとWebFormsを放棄していません（1年前）が、これら2つの技術のいずれかを段階的に廃止することを決定した場合、それを行うのは難しいとは思いません。 WebForms。

私は、ASP.NET MVCが道であることにまったく同意します。それは簡単なことではなく、簡単なことではありませんが、確かにWebFormsよりもはるかに将来的な証拠です。WebFormsは確かに放棄されていませんが、それらを使用するアプリケーションは、アプリケーションがますます大きくなるにつれて、維持するのがますます面倒になります。

「大きな」アプリケーションでのWebFormsの使用は強くお勧めしません。

オプション1）（MVCを使用）は、オプション2）よりもはるかに優れています。2つのアプリをiFrameアプローチのように結合する必要がなく、アプリケーションを段階的に進化させることができるからです。

古いアプリをASP.Netに移行した経験がありますが、2つのアプリ間でセッション状態などのリソースを共有することが課題の1つでした。これは、ユーザーのブラウザからのCookie情報を介して、サーバー側で1つのアプリが他のアプリを呼び出すことで解決できます。もちろん、アプリ間の他の情報共有も、URLルーティングとクエリ文字列を介して行うことができます。これは、MVCの自然なアプローチです。

また、最初に移行する適切なモジュールを特定することは困難な場合がありますが、MVCで開発されているすべての新しい機能から始めて、移行されるガレージでより多くのものが発生するのを防ぐことができます。次に、MVCアプリがリファクタリングの形式になり、古いシステムを使用して予想どおりの結果を確立するため、次に行うべき大幅な手戻りまたはバグ修正のバックログがあるセクションを選択します。このリファクタリング中にユニットテストと自動受け入れテスト（SpecFlow / Watinなど）を追加することで、MVCのテスト容易性も活用することを忘れないでください。後者のタイプのテストの利点の1つは、それらが古いシステムを通過することを確認し、このテストと将来のリファクタリングのために同じコードを新しいコードに適用できることです。