Migration von ASP Classic zu .NET und Schmerzlinderung

Question

Wir sind dabei, den kundenorientierten Bereich unserer Website in .NET 3.5 neu zu gestalten.Bisher lief es gut, wir verwenden denselben Workflow und dieselben gespeicherten Prozeduren. Die größten Änderungen betreffen größtenteils die Benutzeroberfläche, das ORM (von Wörterbüchern zu LINQ) und natürlich die Sprache.Die meisten Seiten waren bisher trivial, aber jetzt arbeiten wir an den umfangreichsten Workflow-Seiten.

Die Hauptseite unseres Angebotsannahmebereichs umfasst 1500 Zeilen, etwa 90 % davon sind ASP, und wahrscheinlich weitere 1000 Zeilen in Funktionsaufrufen für Includes.Ich denke auch, dass die 1500 Zeilen etwas täuschen, da wir mit solchen Edelsteinen arbeiten

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)

Die Standardpraxis, die ich bisher verwendet habe, besteht darin, etwa eine Stunde damit zu verbringen, die App durchzulesen, um mich mit ihr vertraut zu machen, aber auch um auskommentierten/veralteten Code zu entfernen.Dann geht es zunächst um die Tiefenarbeit.Ich fange oben an und kopiere einen Codeabschnitt hinein aspx.cs Datei und beginne mit dem Umschreiben, wobei ich im Laufe der Zeit offensichtliche Umgestaltungen vornehme, insbesondere um die Vorteile unseres ORM zu nutzen.Wenn ich einen Funktionsaufruf bekomme, den wir nicht haben, schreibe ich die Definition auf.

Nachdem ich alles codiert habe, werde ich ein paar Durchgänge zum Refactoring/Testen durchführen.Ich frage mich nur, ob jemand Tipps hat, wie man diesen Prozess ein wenig einfacher/effizienter gestalten kann.

Answer 1

Glauben Sie mir, ich weiß genau Woher kommst du?Ich migriere derzeit eine große App von ASP Classic nach .NET.Und ich lerne immer noch ASP.NET!:S (ja, ich habe schreckliche Angst!).

Die wichtigsten Dinge, die ich im Kopf behalten habe, sind folgende:

• Ich verirre mich nicht zu weit vom aktuellen Design entfernt (d. h.Kein massives „Lasst uns das ALLES rausreißen und es zu ASP.NET magisch machen!“ Aufgrund der unglaublich hohen Kopplung, die ASP Classic normalerweise aufweist, wäre dies sehr gefährlich.Natürlich, wenn Sie zuversichtlich sind, füllen Sie Ihre Fußstapfen :) Dies kann später jederzeit umgestaltet werden.
• Untermauern Sie alles mit Tests, Tests und noch mehr Tests!Ich bemühe mich wirklich, in TDD einzusteigen, aber es ist sehr schwierig, bestehende Apps zu testen. Deshalb stelle ich jedes Mal, wenn ich einen Teil der klassischen Anwendungen entferne und durch .NET ersetze, sicher, dass ich so viele grüne Tests wie möglich hinter mir habe.
• Recherchieren Sie viel, es gibt einige GROSSE Änderungen zwischen Classic und .NET und manchmal kann das, was viele Codezeilen umfassen und in Classic enthalten sein kann, mit wenigen Codezeilen erreicht werden. denken vor dem Codieren..Ich habe das mehrmals auf die harte Tour gelernt :D

Es ist sehr ähnlich wie Spielen Jenga mit deinem Code :)

Viel Glück mit dem Projekt, wenn du noch Fragen hast, dann stelle sie bitte :)

Answer 2

Nachdem ich alles codiert habe, werde ich ein paar Durchgänge zum Refactoring/Testen durchführen.Ich frage mich nur, ob jemand Tipps hat, wie man diesen Prozess ein wenig einfacher/effizienter gestalten kann.

Normalerweise bin ich kein Fan von TDD, aber im Fall von Refactoring ist es wirklich der richtige Weg.

Schreiben Sie zunächst einige Tests, die überprüfen, was das betrachtete Bit tatsächlich tut.Dann umgestalten.Das ist VIEL zuverlässiger als nur „Es sieht so aus, als ob es immer noch funktioniert.“

Der andere große Vorteil besteht darin, dass Sie, wenn Sie etwas weiter unten auf der Seite oder in einer gemeinsam genutzten Bibliothek oder so etwas umgestalten, die Tests einfach erneut ausführen können, anstatt auf die harte Tour herauszufinden, was scheinbar nichts damit zu tun hat ändern War eigentlich verwandt

Answer 3

Sie wechseln vom klassischen ASP zum ASP mit 3.5, ohne einfach alles neu zu schreiben?Skillz.Ich musste mich mit einigen veralteten ASP-@work-Programmen auseinandersetzen und denke, dass es einfach einfacher ist, sie zu analysieren und neu zu schreiben.

Answer 4

Eine ASP-Seite mit 1500 Zeilen?Mit vielen Aufrufen zum Einbinden von Dateien?Sagen Sie es mir nicht – die Funktionen haben keine Namenskonvention, die Ihnen sagt, welche Include-Datei ihre Implementierung hat ...Das weckt Erinnerungen (Schaudern)...

Für mich hört es sich so an, als hätten Sie einen ziemlich soliden Ansatz – ich bin mir nicht sicher, ob es einen magischen Weg gibt, Ihre Schmerzen zu lindern.Nach Ihrem Konvertierungsaufwand wird die Architektur Ihrer App immer noch chaotisch und benutzeroberflächenintensiv sein (d. h.Code-Behind-laufende Workflows), und die Wartung wird wahrscheinlich immer noch ziemlich mühsam sein, aber das Refactoring, das Sie durchführen, sollte auf jeden Fall helfen.

Ich hoffe, Sie haben das Upgrade, das Sie durchführen, gegen ein völliges Neuschreiben abgewogen – solange Sie nicht beabsichtigen, die App zu sehr zu erweitern und nicht in erster Linie für die Wartung der App verantwortlich sind, indem Sie eine komplexe, auf Workflows basierende App wie Sie aktualisieren ist möglicherweise billiger und eine bessere Wahl, als es von Grund auf neu zu schreiben.ASP.NET sollte Ihnen zumindest bessere Möglichkeiten zur Verbesserung der Leistung und Skalierbarkeit bieten als klassisches ASP.Aufgrund Ihrer Frage gehe ich davon aus, dass es für diese Diskussion ohnehin zu spät ist.

Viel Glück!

Answer 5

Klingt, als hätten Sie die Dinge ziemlich gut im Griff.Ich habe viele Leute gesehen, die versucht haben, eine geradlinige Transliteration zu erstellen, inklusive Einbindungen und allem, und es funktioniert einfach nicht.Sie müssen ein gutes Verständnis dafür haben, wie ASP.Net funktionieren möchte, denn das ist so viel unterscheidet sich von Classic ASP, und es hört sich so an, als ob Sie das vielleicht hätten.

Bei größeren Dateien würde ich zunächst versuchen, eine übergeordnete Ansicht zu erhalten.Eine Sache, die mir zum Beispiel aufgefallen ist, ist, dass Classic ASP in Bezug auf Funktionsaufrufe schrecklich war.Sie würden einen Code durchlesen und einen Aufruf einer Funktion finden, ohne eine Ahnung zu haben, wo diese implementiert sein könnte.Daher verfügte der klassische ASP-Code in der Regel über lange Funktionen und Skripte, um diese unangenehmen Sprünge zu vermeiden.Ich erinnere mich, dass ich eine Funktion gesehen habe, die bis zu 40 Seiten ausgedruckt hat!Es macht keinen Spaß, so viel Code direkt zu analysieren.

ASP.Net macht es einfacher, Funktionsaufrufe zu verfolgen, sodass Sie möglicherweise damit beginnen, Ihre größeren Codeblöcke in mehrere kleinere Funktionen aufzuteilen.

Answer 6

Sagen Sie es mir nicht - die Funktionen haben keine Namenskonvention, die Ihnen mitteilt, dass die Datei ihre Implementierung enthält ...Das bringt Erinnerungen zurück (schaudern) ...

Wie hast du das erraten?;)

Ich hoffe, Sie haben das Upgrade abgewogen, das Sie gegen nur von Grund auf neu schreiben-solange Sie nicht beabsichtigen, die App zu stark zu erweitern, und Sie nicht in erster Linie für die Wartung der App verantwortlich sind, wodurch eine komplexe Workflow-basierte App wie Sie aktualisiert wird Tun kann billiger und eine bessere Wahl sein, als es von Grund auf neu umzuschreiben.ASP.NET sollte Ihnen zumindest bessere Möglichkeiten zur Verbesserung der Leistung und Skalierbarkeit bieten als der klassische ASP.Aus Ihrer Frage stelle ich mir vor, dass es sowieso zu spät im Prozess für diese Diskussion ist.

Darüber haben wir gesprochen.Aufgrund des Timings (versucht, die Site eines Mitbewerbers beim Start zu übertreffen) und der Ressourcen (im Wesentlichen zwei Entwickler) war es sinnvoll, die Site nicht aus dem Orbit zu bombardieren.Die Dinge sind tatsächlich viel besser gelaufen, als ich erwartet hatte.Schon in der Planungsphase war uns bewusst, dass dieser Code uns die meisten Probleme bereiten würde.Sie sollten sich den Revisionsverlauf der beteiligten klassischen ASP-Seiten ansehen, es ist ein Blutbad.

Für größere Dateien würde ich versuchen, zuerst eine höhere Ansicht zu erhalten.Eine Sache, die mir beispielsweise aufgefallen ist, ist, dass der klassische ASP schrecklich über Funktionsaufrufe war.Sie würden einen Code lesen und einen Aufruf einer Funktion ohne Ahnung finden, wo er implementiert werden könnte.Infolgedessen hatte der klassische ASP -Code tendenziell lange Funktionen und Skripte, um diese bösen Sprünge zu vermeiden.Ich erinnere mich, dass ich eine Funktion gesehen habe, die auf 40 Seiten ausgedruckt wurde!Es macht keinen Spaß, so viel Code direkt zu durchsuchen.

Die Arbeit mit dem Legacy-Code hat mir tatsächlich ziemlich oft widersprochen, sodass ich über ein recht gutes Verständnis des Systems verfüge.Mit der Funktionslänge haben Sie Recht. Es gibt einige Routinen (die meisten habe ich in viel kleinere umgestaltet), die drei- bis viermal so lang sind wie alle ASPX-Seiten/Hilfsklassen/ORMs auf der neuen Site.

Answer 7

Ich bin einmal auf eine .Net-App gestoßen, die von ASP portiert wurde.Die ASPX-Seiten waren völlig leer.Um die Benutzeroberfläche zu rendern, verwendeten die Entwickler StringBuilders im Code dahinter und führten dann ein „response.write“ aus.Das wäre der falsche Weg!

Answer 8

Ich bin einmal auf eine .Net-App gestoßen, die von ASP portiert wurde.Die ASPX-Seiten waren völlig leer.Um die Benutzeroberfläche zu rendern, verwendeten die Entwickler StringBuilders im Code dahinter und führten dann ein „response.write“ aus.Das wäre der falsche Weg!

Ich habe es andersherum gesehen, der Code hinter der Seite war leer, bis auf die Deklaration von Globals, dann wurde das VBScript im ASPX belassen.