2009-03-25 40 views
8

Tengo una aplicación que quiero (eventualmente) convertir a ASP.NET MVC. Quiero hacer una actualización completa del servicio (a ASP.NET), pero quiero usar material asp actual para ejecutar la funcionalidad actual, de modo que pueda actualizar piezas pequeñas mientras realizo actualizaciones incrementales al nuevo marco. Este sitio es muy dependiente de una DLL VB6 que no está muy desarrollada, por lo que también querremos actualizar esto también, posiblemente reemplazando la funcionalidad actual con servicios web. ¿Hay una solución rápida o esta tarea es una tarea de 3 meses o más? Además, estoy seguro de que se pensó en eso antes, la belleza del MVC es que creo que hay una forma de abordar esto, aunque no estoy seguro de por dónde empezar. ¿Cuál sería la forma más rápida de convertir esta aplicación (en aproximadamente 40 horas), donde puedo hacer pequeños cambios de configuración y hacer que esto funcione en ASP.NET MVC?ASP clásico en ASP.NET MVC (C#)

Respuesta

7

La respuesta corta es ... No se puede. Las diferencias entre asp clásico y asp.net son bastante drásticas, no solo en sintaxis, sino en diseño general. MVC no es solo una implementación similar al ASP clásico aunque puede verse de esa manera. Cualquier conversión tomará tiempo, pensamiento y esfuerzo para que funcione completamente.

Sin embargo, la buena noticia es que puede ejecutarlas SxS para que pueda ejecutar el código asp clásico en un sitio configurado como ASP.NET o ASP.NET MVC. Entonces, con un poco de cinta adhesiva, puede analizar su parte de la solución actualizada por partes.

+0

No quería dar a entender que pensé que eran similares de ninguna manera. Gracias. ¿Puedo preguntar, en la opción lado a lado, hay una manera en que podríamos dejar de registrar el archivo DLL VB6 y hacerlo más fácil de implementar. –

+0

Por lo que yo sé, igual tendrá que registrar el archivo DLL a menos que lo vuelva a escribir (al menos en lo que se refiere al código VB clásico). Con .NET es posible que pueda salirse con la suya creando una interoperabilidad y haciendo referencia a ella localmente, aunque eso no ayudará al código clásico que depende de ello. –

3

Vuelva a escribir su DLL VB6 como un ensamblado .NET COM COMSE. Luego, puede hacer referencia tanto a ASP como a ASP.NET.

Afortunadamente, la mayor parte del trabajo pesado se encuentra en las DLL de VB6. De ser así, puede comenzar a migrar páginas a ASP.NET MVC como lo desee. Debe tener cuidado con la comunicación de página a página: cosas como Sesión y Cookies. Las cookies funcionarán como están, pero tendrá que mover la sesión a algo que se pueda compartir entre MVC y ASP como el servidor Sql. Desafortunadamente, eso requiere volver a escribir sus llamadas de sesión en ASP a otra cosa (posiblemente una envoltura COM alrededor de un componente .NET nuevamente). Sin embargo, buscar y reemplazar debería ser el truco.

En cuanto a la línea de tiempo y la cantidad de trabajo que esto implica, depende bastante del contexto de la cantidad de espagueti en su aplicación actual, de cuánta lógica hay en el DLL vs. ASP y cuántas páginas está migrando.

No creo que 40 horas sean una cantidad de tiempo razonable para ponerme al día con .NET, MVC y reescribir, aunque creo que podrían pasar de 2 a 3 meses.

+0

depende del desarrollador, qué tipo de recursos de capacitación tienen y qué tan "acelerados" deben obtenerlos. empujaría los límites superiores a 6-8 meses –

2

He estado trabajando en un proyecto similar desde hace bastante tiempo; Teníamos una aplicación ASP clásica y queríamos moverla a ASP.Net (usando WebForms). Lo hacemos de a poco, si estamos agregando una nueva página, lo hacemos en .Net y simplemente redirigimos al usuario entre los archivos .asp y .aspx. Trabajar con MVC no debería ser diferente.

El mayor problema que encontramos fue la seguridad; El sitio requiere un inicio de sesión y, por supuesto, la sesión no se comparte entre los dos. Manejamos esto persistiendo los bits de la sesión que nos importa a una tabla en una base de datos y pasando un GUID a través de la cadena de consulta (solo hacemos esto una vez al iniciar sesión, luego borramos el registro de la base de datos para reducir los riesgos de seguridad).