ASP clásico a ASP.net o ASP.net MVC

Tenemos una aplicación web que se desarrolló en ASP clásico y evolucionó durante 5 años a su forma actual que tiene cientos de páginas, una gran base de datos y más de 10000 usuarios activos que pasan por al menos más de 10 páginas al día.

Ahora, queríamos actualizarlo a la última versión de .net. Inicialmente pensamos reescribir toda la aplicación, pero después de analizar el escenario descubrimos que esa no es una opción viable que tampoco muchos expertos sugieren. Todavía no hemos decidido cómo hacerlo de otra manera, pero tenemos algunas ideas sobre cómo lograr la reescritura en las caras.

Opción 1: Pensamos en identificar los módulos principales en esta aplicación y reescribirlos uno por uno separando la aplicación en diferentes capas, como la base de datos (existente), luego la lógica de negocios y la vista. De esta forma, los módulos desarrollados recientemente se agregarán al sistema existente y las páginas nuevas reemplazarán las páginas antiguas de ese módulo en particular. Al mismo tiempo, podemos probar las nuevas capas junto con el sistema anterior y liberarlas una vez que tengamos confianza. También pensamos en desarrollar un tipo de estructura API para la lógica de negocios y se accederá a esta vista como una aplicación externa.

Opción 2: Por el momento, hemos hecho un módulo simple y lo hemos utilizado en la página ASP clásica a través de un IFrame, aunque fue bastante problemático enviar datos entre ASP clásico y la nueva página en el IFrame.

Esto es solo en la etapa de planificación de cómo debemos lograr la reescritura de toda la aplicación sin molestar a la base de usuarios.

Quiero obtener puntos de vista, opiniones y sugerencias de otros programadores sobre si deberíamos acercarnos a este escenario. Si alguien se ha enfrentado a este tipo de escenario, comparta su opinión también.

¿También me gustaría saber que usar ASP.net MVC me va a ayudar en esto?

ACTUALIZACIÓN : Gracias por las dos respuestas por poner sus puntos de vista. Me gustaría obtener más entradas en las dos opciones que especifiqué anteriormente al migrar la aplicación de asp clásico a asp.net o asp.net mvc. Sería de gran ayuda para mí, si todos pueden hacerlo a través de sus puntos de vista, puntos y pensamientos sobre la migración en lugar del punto de elegir asp.net o asp.net mvc.

Déjame comenzar diciendo: "Siento tu dolor, Brutha". Pasé por esto hace 3 años, y desearía que MVC hubiera madurado en ese momento porque la solución de WebForms que diseñé bastante bien se asemeja al modelo MVC sin tener las bibliotecas de Microsoft construidas para mí (por supuesto, hubo varias evidentes "¿Por qué demonios? ¿Hice esas "diferencias"?

También terminé usando iFrames para administrar las diferencias de contenido usando .Net como aplicación principal y asp clásico como esclavo. Desarrollé la arquitectura de framework en .Net y la implementé. Las páginas asp clásicas se "descartaron" de piezas de presentación innecesarias (incluye y otras cosas) y se cargaron en iFrames. Luego, los datos se pasaron a través de la URL utilizando un cifrado personalizado. Para asegurarnos de que la autenticación no se pueda suplantar fácilmente y se acceda a la página al descifrar la cadena de consulta, también empleamos controladores Wildcard en IIS que obligaron a .Net a autenticarse antes de analizar las páginas asp clásicas.

Dado eso, mi recomendación sería ir a MVC de inmediato.

1. MVC le dará acceso a enrutamiento a nivel global.asax. Con la manipulación inteligente de un controlador, puede desarrollar sus modelos de manera adecuada y tener un controlador común que maneje todas las solicitudes asp clásicas según sea necesario.
2. MVC hará que sea muy simple agregar un proyecto de prueba y le permitirá refactorizar piezas de aplicación individuales basadas en la nueva estructura del modelo, al tiempo que proporciona una cobertura de prueba adecuada para asegurarse de que lo está haciendo bien. El valor de esto es absolutamente incalculable porque en cualquier código de refactor la cobertura es una gran preocupación.
3. MVC sigue un enfoque de presentación más programado que WebForms. WebForms intenta mezclarlo todo como si fuera una especie de aplicación con estado (que no lo es), y eso puede ser un choque cultural para las personas acostumbradas al asp clásico. No me malinterpreten, sus desarrolladores van a tener un choque cultural sin importar en qué dirección vayan, pero si pueden quitar algo de ese impacto de la capa de presentación, es posible que encuentren un mayor éxito.

Me gustan tanto WebForms como MVC (aunque admito que con la presentación de Razor me estoy volviendo un poco parcial hacia MVC). Ambos tienen su lugar, y creo que una aplicación como la que usted describe puede ser ideal para una implementación de MVC, particularmente dada la naturaleza "escalonada" que deberá adoptar para implementar piezas de aplicación refactorizadas.

Independientemente del camino que tome, creo que debe asegurarse de que la aplicación .Net sea siempre la aplicación principal cuando se trata de autenticación / autorización / enrutamiento / etc. Un colega mío implementó su migración en una aplicación similar con asp clásico como padre, y tuvo una gran cantidad de problemas cuando finalmente se trató de integrar todo nuevamente.

Optar por ASP.NET MVC no hará que la transición sea más fácil necesariamente, y de hecho puede hacerlo más difícil. Sin embargo, cuando ya ha elegido pasar por esta gran empresa, ¿por qué no tomarse el tiempo para seguir adelante y pasar a la plataforma que mejor se adapte a sus planes?

La migración a ASP.NET (sans MVC) será "más fácil" en el sentido de que generalmente puede hacer puertos rectos de su lógica existente sin tener que hacer una gran refactorización, siempre que no esté haciendo muchas cosas exóticas con ASP clásico. Los resultados serán satisfactorios y relativamente familiares para las personas que ya están familiarizadas con la aplicación. Obtendrá beneficios en el sentido de que cada aplicación portada desde ASP clásico a ASP.NET recibe beneficios .

Migrar a ASP.NET MVC va a ser más trabajo. Es probable que requiera volver a diseñar su modelo de aplicación para que se ajuste al patrón MVC . Esto generalmente es una buena cosa (tm) porque alienta buenos comportamientos como la separación de preocupaciones. Es probable que la aplicación resultante no se parezca mucho a nada que tenga, excepto las piezas lógicas centrales. Obtendrá otras ventajas también . Será un gran cambio cultural y tomará algo de (re) educación del equipo de desarrollo para entender "cómo escribir MVC" correctamente.

Es de destacar que Microsoft no está abandonando WebForms según ScottGu (a partir de hace un año), pero no creo que sea difícil hacer la llamada de que si / cuando deciden eliminar una de estas dos tecnologías, será Formularios web

Estoy totalmente de acuerdo en que ASP.NET MVC es el camino a seguir. No será fácil, no será más fácil, pero ciertamente es mucho más a prueba de futuro que WebForms. Si bien WebForms ciertamente no se ha abandonado, las aplicaciones que las utilizan se vuelven cada vez más engorrosas de mantener a medida que las aplicaciones se hacen cada vez más grandes.

Desaconsejo firmemente el uso de WebForms en aplicaciones "grandes".

Me gusta la Opción 1) (con MVC) mucho mejor que la Opción 2) ya que le permite evolucionar la aplicación de forma incremental, sin tener que acoplar las dos aplicaciones demasiado como lo haría con el enfoque de iFrames.

Tengo cierta experiencia con la migración de una aplicación anterior a ASP.Net y uno de los desafíos fue compartir algunos de los recursos, como el estado de la sesión, entre las dos aplicaciones. Eso se puede resolver haciendo que una aplicación llame a la otra en el lado del servidor a través de la información de cookies del navegador del usuario. Por supuesto, también se puede compartir información entre aplicaciones a través de enrutamiento de URL y cadenas de consulta, que es un enfoque natural con MVC.

Además, identificar los módulos apropiados para migrar primero puede ser un desafío, pero podría comenzar con todas las nuevas funciones que se están desarrollando en MVC para evitar que se migren más cosas en el garaje. Luego, tal vez elija secciones que tengan una gran cantidad de trabajos pendientes o reparaciones de errores que se realizarán a continuación, ya que la aplicación MVC se convertiría en una forma de refactorización, utilizando su sistema anterior para establecer los resultados esperados como sugiere. No olvide aprovechar también la capacidad de prueba de MVC agregando pruebas unitarias y pruebas de aceptación automática (por ejemplo, SpecFlow / Watin) durante esta refactorización. Una ventaja de este último tipo de pruebas es que puede verificar que pasan el sistema anterior y luego aplicar las mismas pruebas a su nuevo código para esta y futuras refactorizaciones.