Migration d'ASP Classic vers .NET et atténuation des difficultés

Question

Nous sommes en train de repenser la section client de notre site dans .NET 3.5.Cela se passe bien jusqu'à présent, nous utilisons le même workflow et les mêmes procédures stockées, pour la plupart, les changements les plus importants sont l'interface utilisateur, l'ORM (des dictionnaires à LINQ) et évidemment le langage.Jusqu'à présent, la plupart des pages étaient triviales, mais nous travaillons désormais sur les pages de flux de travail les plus lourdes.

La page principale de notre section d'acceptation des offres comprend 1 500 lignes, dont environ 90 % sont en ASP, avec probablement 1 000 lignes supplémentaires dans les appels de fonction aux inclusions.Je pense aussi que les 1 500 lignes sont un peu trompeuses puisque nous travaillons avec des joyaux comme celui-ci.

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)

La pratique standard que j'ai utilisée jusqu'à présent consiste à passer environ une heure à lire l'application à la fois pour me familiariser avec elle, mais également pour supprimer le code commenté/obsolète.Puis travailler en profondeur d’abord.Je vais commencer par le haut et copier un segment de code dans le aspx.cs fichier et commencez à réécrire, en faisant des refactorings évidents au fur et à mesure surtout pour profiter de notre ORM.Si je reçois un appel de fonction que nous n'avons pas, j'écrirai la définition.

Une fois que j'ai tout codé, je ferai quelques passes de refactorisation/test.Je me demande simplement si quelqu'un a des conseils sur la façon de rendre ce processus un peu plus facile/plus efficace.

Answer 1

Croyez-moi, je sais exactement d'où tu viens..Je migre actuellement une grande application d'ASP Classic vers .NET.Et j'apprends toujours ASP.NET !:S (oui, je suis terrifiée !).

Les principales choses que j'ai gardées à l'esprit sont les suivantes :

• je ne m'éloigne pas aussi loin de la conception actuelle (c'est-à-direpas de gros "arrachons TOUT cela et rendons ASP.NET magique !) en raison de la quantité incroyablement élevée de couplage qu'ASP classic a tendance à avoir, cela serait très dangereux.Bien sûr, si vous êtes confiant, remplissez vos bottes :) Cela peut toujours être refactorisé plus tard.
• Sauvegardez tout avec des tests, des tests et encore des tests !J'essaie vraiment d'entrer dans TDD, mais il est très difficile de tester les applications existantes, donc chaque fois que je supprime un morceau de classique et que je le remplace par .NET, je m'assure d'avoir autant de tests de feu vert que possible.
• Faites beaucoup de recherches, il y a des changements MAJEURS entre classic et .NET et parfois ce qui peut représenter de nombreuses lignes de code et inclut dans classic peut être réalisé en quelques lignes de code, pense avant de coder..Je l'ai appris à mes dépens, plusieurs fois :D

C'est vraiment comme jouer Jenga avec ton code :)

Bonne chance avec le projet, si vous avez d'autres questions, n'hésitez pas à les poser :)

Answer 2

Une fois que j'ai tout codé, je ferai quelques passes de refactorisation/test.Je me demande simplement si quelqu'un a des conseils sur la façon de rendre ce processus un peu plus facile/plus efficace.

Normalement, je ne suis pas fan de TDD, mais dans le cas du refactoring, c'est vraiment la voie à suivre.

Écrivez d'abord quelques tests qui vérifient ce que fait réellement le bit que vous regardez.Puis refactorisez.C'est BEAUCOUP plus fiable que simplement « on dirait que ça fonctionne toujours ».

L'autre énorme avantage est que lorsque vous refactorisez quelque chose qui se trouve plus bas dans la page, ou dans une bibliothèque partagée ou autre, vous pouvez simplement réexécuter les tests, au lieu de découvrir à la dure qu'un élément apparemment sans rapport changement était effectivement lié

Answer 3

Vous passez de l'ASP classique à l'ASP 3.5 sans juste réécrire ?Skillz.J'ai dû gérer certains anciens ASP @work et je pense qu'il est tout simplement plus facile de l'analyser et de le réécrire.

Answer 4

Une page ASP de 1 500 lignes ?Avec de nombreux appels pour inclure des fichiers ?Ne me dites pas - les fonctions n'ont aucune convention de dénomination qui vous indique quel fichier d'inclusion a leur implémentation...Ça rappelle des souvenirs (frémir)...

Il me semble que vous avez une approche assez solide – je ne sais pas s'il existe un moyen magique d'atténuer votre douleur.Après votre effort de conversion, l'architecture de votre application sera toujours compliquée et lourde en termes d'interface utilisateur (c'est-à-direworkflows d'exécution de code-behind), et cela sera probablement encore assez pénible à maintenir, mais la refactorisation que vous effectuez devrait certainement aider.

J'espère que vous avez pesé la balance entre la mise à niveau que vous effectuez et une simple réécriture à partir de zéro - tant que vous n'avez pas l'intention de trop étendre l'application et que vous n'êtes pas principalement responsable de la maintenance de l'application, de la mise à niveau d'une application complexe basée sur un flux de travail comme vous ce que nous faisons peut être moins cher et constitue un meilleur choix que de le réécrire à partir de zéro.ASP.NET devrait au moins vous offrir de meilleures opportunités d’améliorer les performances et l’évolutivité que l’ASP classique.D'après votre question, j'imagine qu'il est de toute façon trop tard dans le processus pour cette discussion.

Bonne chance!

Answer 5

On dirait que vous maîtrisez assez bien les choses.J'ai vu beaucoup de gens essayer de faire une translittération en ligne droite, inclusions et tout, et cela ne fonctionne tout simplement pas.Vous devez bien comprendre comment ASP.Net veut fonctionner, car c'est beaucoup différent de l'ASP classique, et il semble que vous l'ayez peut-être.

Pour les fichiers plus volumineux, j’essaierais d’abord d’obtenir une vue de niveau supérieur.Par exemple, une chose que j'ai remarquée est que l'ASP classique était horrible en matière d'appels de fonctions.Vous liriez du code et trouveriez un appel à une fonction sans aucune idée de l'endroit où elle pourrait être implémentée.En conséquence, le code ASP classique avait tendance à avoir des fonctions et des scripts longs pour éviter ces vilains sauts.Je me souviens avoir vu une fonction qui imprimait jusqu'à 40 pages !Analyser directement autant de code n’est pas amusant.

ASP.Net facilite le suivi des appels de fonction. Vous pouvez donc commencer par diviser vos blocs de code plus volumineux en plusieurs fonctions plus petites.

Answer 6

Ne me le dites pas - les fonctions n'ont pas de convention de dénomination qui vous indique que le fichier inclue a leur implémentation ...Cela ramène des souvenirs (frisson) ...

Comment as-tu deviné?;)

J'espère que vous avez pesé la mise à niveau que vous faites contre la simple réécriture à partir de zéro - tant que vous n'avez pas l'intention d'étendre trop l'application et que vous n'êtes pas principalement responsable du maintien de l'application, de la mise à niveau d'une application basée sur un workflow complexe comme vous Le fait peut être moins cher et un meilleur choix que de le réécrire à partir de zéro.ASP.NET devrait vous offrir de meilleures opportunités d'améliorer les performances et l'évolutivité, au moins, que l'ASP classique.D'après votre question, j'imagine qu'il est de toute façon trop tard dans le processus pour cette discussion.

C'est quelque chose dont nous avons parlé.Sur la base du timing (essayer de battre le site d'un concurrent pour le lancement) et des ressources (essentiellement deux développeurs), il était logique de ne pas faire sortir le site de son orbite.Les choses se sont en fait bien mieux passées que ce à quoi je m’attendais.Nous étions conscients dès les étapes de planification que ce code allait nous poser le plus de problèmes.Vous devriez voir l’historique des révisions des pages ASP classiques concernées, c’est un bain de sang.

Pour les fichiers plus grands, j'essaierais d'abord d'obtenir une vue de niveau supérieur.Par exemple, une chose que j'ai remarquée est que l'ASP classique était horrible à propos des appels de fonction.Vous lirez un code et trouveriez un appel à une fonction sans aucune idée de l'endroit où il pourrait être implémenté.En conséquence, le code ASP classique avait tendance à avoir de longues fonctions et scripts pour éviter ces sauts désagréables.Je me souviens avoir vu une fonction imprimée à 40 pages!Analyser directement à travers autant de code n'est pas amusant.

En fait, j'ai souvent eu ce mécontentement à l'idée de travailler avec le code existant, j'ai donc une bonne compréhension de haut niveau du système.Vous avez raison sur la longueur de la fonction, il existe certaines routines (la plupart que j'ai refactorisées en des routines beaucoup plus petites) qui sont 3 à 4 fois plus longues que n'importe laquelle des pages aspx/classes d'assistance/ORM du nouveau site.

Answer 7

Une fois, je suis tombé sur une application .Net portée depuis ASP.Les pages .aspx étaient totalement vierges.Pour restituer l'interface utilisateur, les développeurs ont utilisé StringBuilders dans le code sous-jacent, puis ont effectué une réponse.write.Ce serait une mauvaise façon de procéder !

Answer 8

Une fois, je suis tombé sur une application .Net portée depuis ASP.Les pages .aspx étaient totalement vierges.Pour restituer l'interface utilisateur, les développeurs ont utilisé StringBuilders dans le code sous-jacent, puis ont effectué une réponse.write.Ce serait une mauvaise façon de procéder !

Je l'ai vu faire dans l'autre sens, le code derrière la page était vide, à l'exception de la déclaration des globales, puis le VBScript a été laissé dans l'ASPX.