asp.net - ASPクラシックから.NETへの移行と痛みの軽減

Question

現在、.NET3.5でサイトの顧客向けセクションを再設計しています。これまでのところ順調に進んでおり、同じワークフローとストアドプロシージャを使用しています。ほとんどの場合、最大の変更点はUI、ORM（辞書からLINQへ）、そして明らかに言語です。これまでのほとんどのページは些細なものでしたが、現在は最も重いワークフローページに取り組んでいます。

オファー受け入れセクションのメインページは1500行で、その約90％がASPであり、関数呼び出しにさらに1000行が含まれている可能性があります。このような宝石を扱っているので、1500行も少しだまされていると思います

function GetDealText(sUSCurASCII, sUSCurName, sTemplateOptionID, sSellerCompany, sOfferAmount, sSellerPremPercent, sTotalOfferToSeller, sSellerPremium, sMode, sSellerCurASCII, sSellerCurName, sTotalOfferToSeller_SellerCurr, sOfferAmount_SellerCurr, sSellerPremium_SellerCurr, sConditions, sListID,  sDescription, sSKU, sInv_tag, sFasc_loc, sSerialNoandModel, sQTY, iLoopCount, iBidCount, sHTMLConditions, sBidStatus, sBidID, byRef bAlreadyAccepted, sFasc_Address1, sFasc_City, sFasc_State_id, sFasc_Country_id, sFasc_Company_name, sListingCustID, sAskPrice_SellerCurr, sMinPrice_SellerCurr, sListingCur, sOrigLocation)

私がこれまで使用してきた標準的な方法は、アプリを1時間ほど読んで、アプリに慣れるためだけでなく、コメントアウト/非推奨のコードを取り除くことです。次に、深さ優先の方法で作業します。一番上から始めて、ファイル内のコードのセグメントをコピーしてaspx.cs書き直しを開始します。特にORMを利用するために、明らかなリファクタリングを行います。持っていない関数呼び出しを受け取ったら、定義を書きます。

すべてをコーディングしたら、リファクタリング/テストでいくつかのパスを実行します。このプロセスをもう少し簡単/効率的にする方法について誰かがヒントを持っているかどうか疑問に思っています。

score 6 · Accepted Answer

私を信じてください、私はあなたがどこから来ているのかを正確に知っています..私は現在ASPクラシックから.NETに大きなアプリを移行しています..そして私はまだASP.NETを学んでいます！：S（はい、私はおびえています！）。

私が心に留めている主なことはこれです：

ASPクラシックの結合量が非常に多いため、現在の設計から大きく外れることはありません（つまり、「これをすべて取り除いてASP.NETを魔法のようにする」ことはできません）。これは非常に危険です。もちろん、自信がある場合は、ブーツをいっぱいにしてください:)これはいつでも後でリファクタリングできます。
テスト、テスト、その他のテストですべてをバックアップしてください！私はTDDに取り掛かろうと懸命に努力していますが、既存のアプリをテストするのは非常に難しいので、クラシックのチャンクを削除して.NETに置き換えるたびに、できるだけ多くの青信号テストを行うようにしています。
多くの調査を行います。classicと.NETの間にはいくつかの大きな変更があり、場合によっては、何行ものコードであり、classicに含まれるものは、数行のコードで実現できます。コーディングする前に考えてください。これは難しい方法で学びました。、数回：D

それはあなたのコードでJengaをプレイするのと非常によく似ています:)

プロジェクトの幸運を祈ります。他に質問がある場合は、質問してください:)

score 2 · Accepted Answer

すべてをコーディングしたら、リファクタリング/テストでいくつかのパスを実行します。このプロセスをもう少し簡単/効率的にする方法について誰かがヒントを持っているかどうか疑問に思っています。

間違ったこと

通常、私はTDDのファンではありませんが、リファクタリングの場合は、実際にそれを実行する方法です。

あなたが見ているビットが実際に何をしているのかを検証するいくつかのテストを最初に書いてください。次に、リファクタリングします。これは、「まだ機能しているように見える」よりもはるかに信頼性があります。

これのもう1つの大きな利点は、ページのさらに下にあるもの、または共有ライブラリなどでリファクタリングするときに、一見無関係に見える難しい方法を見つけるのではなく、テストを再実行できることです。変化は実際に関連していた

score 1 · Accepted Answer

書き直すだけで、従来のASPから3.5のASPに移行しますか？スキルズ。従来のASP@workを処理する必要がありましたが、解析して書き直す方が簡単だと思います。

score 1 · Accepted Answer

1500行のASPページ？ファイルを含めるための呼び出しがたくさんありますか？私に言わないでください-関数には、どのインクルードファイルに実装があるかを示す命名規則がありません...それは記憶を呼び戻します（震え）...

あなたはかなり堅実なアプローチをしているように私には聞こえます-あなたの痛みを和らげる魔法の方法があるかどうかはわかりません。変換作業後も、アプリのアーキテクチャは依然として乱雑でUIが多く（つまり、実行中のワークフローのコードビハインド）、維持するのはおそらくかなり苦痛ですが、実行しているリファクタリングは間違いなく役立つはずです。

アプリをあまり拡張するつもりがなく、アプリのメンテナンス、あなたのような複雑なワークフローベースのアプリのアップグレードに主に責任がない限り、あなたが行っているアップグレードと、最初から書き直すだけのアップグレードを比較検討したことを願っていますやっているのは、最初から書き直すよりも安くて良い選択かもしれません。ASP.NETは、少なくともクラシックASPよりもパフォーマンスとスケーラビリティを向上させるためのより良い機会を提供するはずです。あなたの質問から、とにかくその議論のプロセスには遅すぎると思います。

幸運を！

score 0 · Accepted Answer

ASPから移植された.Netアプリに出くわしたことがあります。.aspxページは完全に空白でした。UIをレンダリングするために、開発者はコードビハインドでStringBuildersを使用してから、response.writeを実行しました。これは間違った方法です！

score 0 · Accepted Answer

ASP から移植された .Net アプリに出くわしたことがあります。.aspx ページは完全に空白でした。UI をレンダリングするために、開発者はコードビハインドで StringBuilders を使用してから、response.write を実行しました。これは間違った方法です。

グローバルの宣言を除いて、コードビハインドページは空白で、VBScript は ASPX に残されていました。

score 0 · Accepted Answer

あなたは物事をかなりうまく処理しているようですね。私は、多くの人が直線的な音訳を行おうとしているのを見てきました。ASP.Net は従来の ASP とは大きく異なるため、ASP.Net がどのように動作するかを十分に理解している必要があります。

大きなファイルの場合は、まず上位レベルのビューを取得しようとします。たとえば、私が気づいたことの 1 つは、Classic ASP が関数呼び出しに関してひどいものだったことです。いくつかのコードを読んでいて、関数の呼び出しを見つけて、それが実装されている可能性がある場所についての手がかりがありません。その結果、従来の ASP コードは、これらの厄介なジャンプを避けるために、長い関数とスクリプトを持つ傾向がありました。40ページに印刷する機能を見たのを覚えています! それほど多くのコードをそのまま解析するのは楽しくありません。

ASP.Net を使用すると、関数呼び出しを簡単に追跡できるため、大きなコードブロックをいくつかの小さな関数に分割することから始めることができます。

score 0 · Accepted Answer

言わないでください-関数には、どのインクルードファイルに実装があるかを示す命名規則がありません...それは思い出を呼び戻します(身震い)...

どのように推測しましたか？;)

アプリをあまり拡張するつもりがなく、主にアプリの保守を担当しておらず、複雑なワークフローベースのアプリをアップグレードしている場合に限り、ゼロから書き直すだけでアップグレードを行うことを検討していただければ幸いです。している方が、ゼロから書き直すよりも安くて良い選択かもしれません。ASP.NET は、少なくとも従来の ASP よりも、パフォーマンスとスケーラビリティを向上させるより良い機会を提供するはずです。あなたの質問から、とにかくその議論のプロセスでは遅すぎると思います。

これは私たちが話したことでした。タイミング (競合他社のサイトを打ち負かして立ち上げようとする) とリソース (基本的に 2 人の開発者) に基づいて、軌道からサイトを核攻撃しないことは理にかなっています。実際、物事は私が予想していたよりもはるかにうまくいっています。計画段階から、このコードが最も問題になることはわかっていました。関連する従来の ASP ページの改訂履歴が表示されるはずです。これは大惨事です。

大きなファイルの場合は、まず上位レベルのビューを取得しようとします。たとえば、私が気づいたことの 1 つは、Classic ASP が関数呼び出しに関してひどいものだったことです。いくつかのコードを読んでいて、関数の呼び出しを見つけて、それがどこに実装されているかについての手がかりを見つけるでしょう。その結果、従来の ASP コードは、これらの厄介なジャンプを避けるために、長い関数とスクリプトを持つ傾向がありました。40ページに印刷する機能を見たのを覚えています! それほど多くのコードをそのまま解析するのは楽しくありません。

私は実際、レガシーコードをかなり操作することに不満を持っていたので、システムについてかなりの高レベルの理解を持っています。関数の長さについては正しいです。新しいサイトの aspx ページ/ヘルパークラス/ORM の 3 ～ 4 倍の長さのルーチンがいくつかあります (ほとんどのルーチンは、はるかに小さいものにリファクタリングしました)。

asp.net - ASPクラシックから.NETへの移行と痛みの軽減

8 に答える 8

Related

Reference