Migración de ASP Classic a .NET y mitigación de problemas

Question

Estamos en el proceso de rediseñar la sección orientada al cliente de nuestro sitio en .NET 3.5.Ha ido bien hasta ahora, estamos usando el mismo flujo de trabajo y procedimientos almacenados, en su mayor parte, los cambios más importantes son la interfaz de usuario, el ORM (de diccionarios a LINQ) y, obviamente, el idioma.La mayoría de las páginas hasta este punto han sido triviales, pero ahora estamos trabajando en las páginas de flujo de trabajo más pesadas.

La página principal de nuestra sección de aceptación de ofertas tiene 1500 líneas, aproximadamente el 90% de ellas es ASP, con probablemente otras 1000 líneas en llamadas de función a inclusiones.Creo que las 1500 líneas también son un poco engañosas ya que estamos trabajando con gemas como esta.

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 práctica estándar que he estado usando hasta ahora es pasar aproximadamente una hora leyendo la aplicación para familiarizarme con ella, pero también para eliminar el código comentado/obsoleto.Luego, trabajar primero en profundidad.Comenzaré desde arriba y copiaré un segmento de código en el aspx.cs archivo y comenzar a reescribir, haciendo refactorizaciones obvias a medida que avanzo, especialmente para aprovechar nuestro ORM.Si recibo una llamada de función que no tenemos, escribiré la definición.

Después de tener todo codificado, haré algunas pasadas de refactorización/prueba.Me pregunto si alguien tiene algún consejo sobre cómo hacer que este proceso sea un poco más fácil o más eficiente.

Answer 1

Créeme, lo sé exactamente de donde vienes..Actualmente estoy migrando una aplicación grande de ASP clásico a .NET.¡Y todavía estoy aprendiendo ASP.NET!:S (¡sí, estoy aterrorizada!).

Lo principal que tengo en mente es esto:

• no me desvío también lejos del diseño actual (es decir,no masivo "¡eliminemos TODO esto y hagamos que ASP.NET sea mágico!) debido a la increíblemente alta cantidad de acoplamiento que tiende a tener ASP clásico, esto sería muy peligroso.Por supuesto, si tienes confianza, ponte manos a la obra :) Esto siempre se puede refactorizar más adelante.
• ¡Respalde todo con pruebas, pruebas y más pruebas!Realmente me estoy esforzando mucho por ingresar a TDD, pero es muy difícil probar aplicaciones existentes, por lo que cada vez que elimino una parte del clásico y lo reemplazo con .NET, me aseguro de tener tantas pruebas de luz verde respaldándome como sea posible.
• Investigue mucho, hay algunos cambios IMPORTANTES entre el clásico y .NET y, a veces, lo que pueden ser muchas líneas de código e incluye en el clásico se puede lograr en unas pocas líneas de código. pensar antes de codificar...He aprendido esto de la manera más difícil, varias veces :D

Es muy parecido a jugar jenga con tu código :)

Mucha suerte con el proyecto, si tienes más preguntas, por favor pregunta :)

Answer 2

Después de tener todo codificado, haré algunas pasadas de refactorización/prueba.Me pregunto si alguien tiene algún consejo sobre cómo hacer que este proceso sea un poco más fácil o más eficiente.

Normalmente no soy un fanático de TDD, pero en el caso de refactorizar realmente es el camino a seguir.

Primero escriba algunas pruebas que verifiquen qué está haciendo realmente el bit que está mirando.Luego refactorice.Esto es MUCHO más confiable que simplemente "parece que todavía funciona".

El otro gran beneficio de esto es que cuando estás refactorizando algo que está más abajo en la página, o en una biblioteca compartida o algo así, puedes simplemente volver a ejecutar las pruebas, en lugar de descubrir por las malas que un archivo aparentemente no relacionado cambiar era realmente relacionado

Answer 3

¿Vas a pasar del ASP clásico al ASP 3.5 sin solo reescribirlo?Habilidad.Tuve que lidiar con algunos ASP @work heredados y creo que es más fácil analizarlos y reescribirlos.

Answer 4

¿Una página ASP de 1500 líneas?¿Con muchas llamadas para incluir archivos?No me digas: las funciones no tienen ninguna convención de nomenclatura que te indique qué archivo de inclusión tiene su implementación...Eso me trae recuerdos (estremecimiento)...

Me parece que tienes un enfoque bastante sólido; no estoy seguro de si existe alguna forma mágica de mitigar tu dolor.Después de su esfuerzo de conversión, la arquitectura de su aplicación seguirá siendo desordenada y con mucha interfaz de usuario (es decir,código subyacente en ejecución de flujos de trabajo), y probablemente seguirá siendo bastante complicado de mantener, pero la refactorización que está realizando definitivamente debería ayudar.

Espero que hayas sopesado la actualización que estás realizando frente a simplemente reescribir desde cero, siempre y cuando no tengas la intención de ampliar demasiado la aplicación y no seas el principal responsable de mantenerla, actualizando una aplicación compleja basada en flujo de trabajo como tú. lo que estamos haciendo puede ser más barato y una mejor opción que reescribirlo desde cero.ASP.NET debería brindarle mejores oportunidades para mejorar el rendimiento y la escalabilidad, al menos, que el ASP clásico.Por su pregunta, imagino que de todos modos ya es demasiado tarde en el proceso para esa discusión.

¡Buena suerte!

Answer 5

Parece que tienes un buen manejo de las cosas.He visto a mucha gente intentar hacer una transliteración en línea recta, con todo incluido, y simplemente no funciona.Es necesario tener una buena comprensión de cómo quiere funcionar ASP.Net, porque es mucho diferente del ASP clásico y parece que tal vez lo tengas.

Para archivos más grandes, primero intentaría obtener una vista de nivel superior.Por ejemplo, una cosa que he notado es que el ASP clásico era horrible con las llamadas a funciones.Estaría leyendo algún código y encontraría una llamada a una función sin tener idea de dónde podría implementarse.Como resultado, el código ASP clásico tendía a tener funciones y scripts largos para evitar esos saltos desagradables.¡Recuerdo haber visto una función que imprimía 40 páginas!Analizar directamente tanto código no es divertido.

ASP.Net hace que sea más fácil seguir las llamadas a funciones, por lo que puede comenzar dividiendo los bloques de código más grandes en varias funciones más pequeñas.

Answer 6

No me digas: las funciones no tienen ninguna convención de nomenclatura que le indique que incluya el archivo que tenga su implementación ...Eso trae recuerdos (estremecimiento) ...

¿Como adivinaste?;)

Espero que hayas sopesado la actualización que estás haciendo contra solo reescribir desde cero, siempre que no tengas la intención de extender demasiado la aplicación y no eres el principal responsable de mantener la aplicación, actualizar una aplicación compleja basada en flujo de trabajo como tu Estar, puede ser más barato y una mejor opción que reescribirlo desde cero.ASP.NET debería brindarle mejores oportunidades para mejorar el rendimiento y la escalabilidad, al menos, que ASP clásico.De su pregunta, imagino que es demasiado tarde en el proceso para esa discusión de todos modos.

Esto fue algo de lo que hablamos.Según el tiempo (tratar de ganarle al sitio de un competidor para el lanzamiento) y los recursos (básicamente dos desarrolladores), tenía sentido no bombardear el sitio desde la órbita.De hecho, las cosas han ido mucho mejor de lo que esperaba.Éramos conscientes incluso desde las etapas de planificación de que este código nos iba a dar la mayor cantidad de problemas.Deberías ver el historial de revisiones de las páginas ASP clásicas involucradas, es un baño de sangre.

Para archivos más grandes, intentaría obtener una vista de nivel más alta primero.Por ejemplo, una cosa que he notado es que el ASP clásico fue horrible sobre las llamadas de funciones.Estaría leyendo algún código y encontrará una llamada a una función sin idea de dónde podría implementarse.Como resultado, el código ASP clásico tendió a tener funciones y guiones largos para evitar esos saltos desagradables.¡Recuerdo haber visto una función que imprimió a 40 páginas!Analizar directamente ese código no es divertido.

De hecho, he tenido bastante disgusto al trabajar con el código heredado, por lo que tengo un alto nivel de comprensión del sistema.Tienes razón sobre la longitud de la función, hay algunas rutinas (la mayoría las he refactorizado en otras mucho más pequeñas) que son de 3 a 4 veces más largas que cualquiera de las páginas aspx/clases auxiliares/ORM en el nuevo sitio.

Answer 7

Una vez me encontré con una aplicación .Net portada desde ASP.Las páginas .aspx estaban totalmente en blanco.Para representar la interfaz de usuario, los desarrolladores utilizaron StringBuilders en el código subyacente y luego hicieron una respuesta.¡Esta sería la forma incorrecta de hacerlo!

Answer 8

Una vez me encontré con una aplicación .Net portada desde ASP.Las páginas .aspx estaban totalmente en blanco.Para representar la interfaz de usuario, los desarrolladores utilizaron StringBuilders en el código subyacente y luego hicieron una respuesta.¡Esta sería la forma incorrecta de hacerlo!

Lo he visto hecho de otra manera, el código detrás de la página estaba en blanco, excepto la declaración de globales, luego el VBScript se dejó en ASPX.