從ASP Classic遷移到.NET並緩解疼痛

Question

我們正在.NET 3.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) 

我一直使用至今的標準做法是，也許要花一個小時左右閱讀過的應用程序既熟悉它，但也可以去除註釋/棄用的代碼。然後以深度優先的方式工作。我將從頂層開始，複製aspx.cs文件中的一段代碼，並開始重寫，在我走的時候做出明顯的重構，特別是利用我們的ORM。如果我得到一個我們沒有的函數調用，我會寫出這個定義。

在我編寫了所有代碼之後，我會在重構/測試中做一些傳遞。我只是想知道如果任何人有任何提示，如何使這個過程更容易/更有效。

Answer 1

相信我，我知道確切其中你是從哪裏來的..我目前遷移從ASP經典到.NET的大型應用程序。而我仍然在學習ASP 。淨！ ：S（是的，我很害怕！）。

我一直在我腦海裏的主要事情是這樣的：

• 我不雜散太遠離當前設計（即沒有出現大規模「讓撕了這一切並使其ASP.NET不可思議的！）由於ASP經典版本的耦合量非常高，所以這會非常危險。當然，如果你有信心，請填寫你的靴子:)以後總是可以重新構建這些東西
• 與測試，測試和更多測試！我真的很難進入TDD，但它很難測試現有的應用程序，所以每次我刪除一大塊經典代碼並用.NET代替時，我確保我有儘可能多的支持綠燈的測試。
• 研究很多，經典和.NET之間有一些主要的變化，有時候可以是許多代碼行，包括經典的可以在幾行代碼中實現，認爲在編碼之前。這種痛苦的滋味，幾次：d

它非常喜歡打Jenga與您的代碼:)

最佳運氣的項目，更多的問題，那麼請諮詢:)

Answer 2

你將從傳統的ASP到3.5的ASP而不只是重寫？的skillz。我不得不處理一些傳統的ASP @work，我認爲解析它並重寫它更容易。

Answer 3

當我編碼完成所有事情之後，我會在重構/測試中做幾個通過。我只是想知道如果任何人有任何提示，如何使這個過程更容易/更有效。

通常我不是TDD的粉絲，但在真正重構它的情況是要走的路。

先寫一些測試來驗證你正在看的位是在做什麼。然後重構。這比LOT更可靠，它看起來仍然有效。

另一個巨大的好處是，當你重構更深層頁面或共享庫或其他東西時，你可以重新運行測試，而不是找出困難的方式一個看似無關的變化被實際上與

Answer 4

聽起來像你有一個很好的處理事情。我看到很多人試圖做直線音譯，包括所有，而且它不起作用。您需要對ASP.Net的工作原理有一個很好的理解，因爲它的的與傳統的ASP不同，聽起來也許你有這個想法。

對於較大的文件，我會嘗試先獲得更高級別的視圖。例如，我注意到的一件事是，經典的ASP對函數調用來說太可怕了。你會閱讀一些代碼，並找到一個函數的調用，而不知道它可能在哪裏實現。因此，經典ASP代碼傾向於具有較長的函數和腳本以避免這些討厭的跳轉。我記得看到一個打印到40頁的功能！直接解析這麼多的代碼並不好玩。

ASP.Net可以更輕鬆地跟蹤函數調用，因此您可以先將較大的代碼塊分解爲幾個較小的函數。

Answer 5

一個1500行的ASP頁面？有很多電話打包文件？不要告訴我 - 功能沒有任何命名約定，告訴你哪個包含文件有他們的實現...這帶來回憶（不寒而慄）...

這聽起來像我喜歡你有一個非常可靠的方法 - 我不確定是否有任何神奇的方法來減輕你的痛苦。在您的轉換工作完成後，您的應用程序的體系結構仍然很混亂，並且會佔用大量UI（即，代碼隱藏的正在運行的工作流程），並且可能仍然很難維護，但您所做的重構肯定會有所幫助。

我希望您已經權衡了您正在從頭開始重寫的升級 - 只要您不打算擴展應用程序太多，並且您不主要負責維護應用程序，升級複雜的工作流程，像你正在做的基於應用程序的應用程序可能比從零開始重寫它更便宜和更好的選擇。至少，與ASP.NET相比，ASP.NET應該爲您提供更好的機會來提高性能和可伸縮性。從你的問題來看，我認爲在討論過程中已經太遲了。

祝你好運！

Answer 6

不要告訴我 - 的功能不 有任何命名約定，告訴你 包括文件都有自己的 實現......這勾起回憶 （戰慄）...

你是怎麼猜到的？;）

我希望你權衡你做對從頭開始重寫剛在 升級 - 只要你不打算 延長應用程序太多 ，你是不是主要負責 維護應用程序，升級 複雜的基於工作流程的應用程序，如 正在做的可能比從零開始重寫它更便宜並且更好 選擇。 ASP.NET應該給你提供更好的機會來提高性能 和可擴展性，至少比經典ASP的 。從你的問題I 想象，無論如何，這個討論的 過程已經太遲了。

這是我們談到的。基於時機（試圖擊敗競爭對手的網站發佈）和資源（基本上是兩個開發人員），不要將該網站從軌道上移開是有意義的。事情實際上比我預期的要好得多。我們甚至從計劃階段就知道這個代碼會給我們帶來最多的問題。你應該看到涉及的經典ASP頁面的修訂歷史，這是一場血洗。

對於較大的文件，我會試着首先得到一個 更高級別的視圖。例如， 我注意到的一點是，經典的 ASP對於函數調用來說太可怕了。 你會閱讀一些代碼和 找到一個函數的調用，不知道它可能實現的地方。 因此，經典ASP代碼傾向於 具有長功能和腳本，以避免那些討厭的跳躍。我記得 看到一個功能，打印到 40頁！直接解析 那麼多代碼就沒有趣味。

實際上，我對遺留代碼的工作有點不滿，所以我對系統有很高層次的理解。你對函數的長度是正確的，有一些例程（大多數我已經重構爲更小的例程），這些例程與新站點上的任何aspx頁面/輔助類/ ORM一樣長3-4倍。

Answer 7

我曾經遇到過一個從ASP移植過來的.Net應用程序。 .aspx頁面完全空白。爲了呈現UI，開發人員在代碼背後使用了StringBuilders，然後執行了response.write。這將是錯誤的做法！

Answer 8

我曾經遇到過一個從ASP移植過來的.Net應用程序。 .aspx頁面完全空白。爲了呈現UI，開發人員在代碼背後使用了StringBuilders，然後執行了response.write。這將是錯誤的做法！

我已經看到它做了另一種方式，頁面後面的代碼是空白的，除了全局聲明，然後VBScript留在ASPX。