2009-02-11 24 views
10

Estoy haciendo algo de mantenimiento en una aplicación ASP clásica para mi cliente, y mientras busco en el ASP, me viene a la mente la siguiente pregunta: ¿sería más fácil convertir una aplicación ASP clásica a ASP.NET MVC o ASP.NET WebForms?Migración de ASP clásico: formas web o ASP.NET MVC?

En muchos sentidos, parece que al menos el HTML de ASP podría ser más fácil de convertir a MVC de lo que sería arrancar los fragmentos HTML y convertirlos en controles ASP.NET, repetidores, datagrids, etc. Además tener que agregar en el manejo y la lógica para ViewState, etc. podría ser un trabajo adicional.

No creo que mi cliente vaya a solicitar ninguna actualización como esta, así que esto es simplemente teórico.

Supongamos que este código ASP está escrito muy bien (lo que no siempre es cierto, por supuesto), realmente la pregunta es: ¿un sitio ASP mejor diseñado y mejor en el caso migrará mejor a MVC que WebForms?

(Tenga en cuenta que soy muy nuevo en ASP.NET MVC, por lo que podría estar perdiendo algo crucial aquí).

Respuesta

7

Depende mucho de cómo esté estructurada la aplicación asp clásica.

La etiqueta de servidor mezclada con HTML es similar a asp.net mvc, pero MVC no es tan desordenada (o no se supone que sea). Es posible que pueda mover el código de presentación ASP clásico a una vista MVC más fácil que a un formulario web. También las aplicaciones de asp clásicas se desarrollaron generalmente teniendo en cuenta la apatridia de la web. Probablemente no haya nada en tu asp clásico que coincida con postabacks o viewstate. ASP clásico también utiliza elementos html normales en oposición a los controles de formularios web asp.net. En estos aspectos, coincide con MVC mucho más cerca que las formas web.

Si no conoce asp.net webforms o asp.net mvc, diría que MVC es el camino a seguir.

Si conoce muy bien los formularios web y no sabe mucho sobre MVC, diría que los formularios web es el camino a seguir.

Pero, si su cliente por alguna razón quiere una remodelación del sitio, yo diría que vaya con MVC. Siempre es bueno que un cliente pague una parte del desarrollo de su experiencia siempre que pueda realizar un trabajo.

En otra nota, siempre estoy sorprendido cuando me encuentro con un cliente que quiere que trabaje en su clásico sitio asp. En cada caso, el sitio es un desastre. La peor parte es que generalmente están llenos de enormes agujeros de seguridad.

2

ASP.NET-MVC es mucho más que las aparentes similitudes entre el código de vista y el código en línea ASP. Hay todas las partes del Modelo y del Controlador a considerar, que es muy diferente de la forma en que se escribe la mayoría de las ASP.

Dicho esto, diría que MVC sería el mejor lugar para comenzar.

1

IMO WebForms intento ocultar html demasiado a mi gusto y puede hacer que su proyecto tarde más de lo que desea debido a la conversión de una gran cantidad de html en los controles de formularios web.

Por otro lado, MVC le permite reutilizar parte de esta lógica mientras hace que su aplicación sea mucho más fácil de mantener y con el Patrón Arquitectónico adecuado su aplicación puede desarrollarse y refactorizarse mucho más rápido que cualquier proyecto de WebForms.

¡Digo MVC todo el camino!

4

Creo que en muchos casos podría ser más fácil convertir a MVC que Webforms. La mayoría de las aplicaciones ASP clásicas muestran muy poca separación de las preocupaciones, por lo que probablemente la tarea más importante sea exactamente eso, separando la lógica en acceso a datos, lógica de negocios, entidades comerciales y componentes de UI. Al hacerlo, podría ser más fácil convertir el código ASP en línea a una vista, la lógica comercial en controladores y las entidades comerciales en el modelo.

4

No creo que una sea más fácil de convertir que la otra.

Puede codificar ASP.NET casi de la misma manera que codifica ASP si quisiera poner algunos elementos cruciales en el código subyacente al que podía acceder en el aspx. Sin enlace de datos, sin vista de cuadrícula y sin repetidor. El estado de la vista está ahí para ayudarlo, es fácil de entender, no es necesario usarlo si no lo desea y puede desactivarse en el archivo web.config y activarse con un atributo de página. Los formularios web también tienen un modo AspCompat que permite el acceso a los objetos Request o Response o asp, que permitirán la conversión de página por página si así lo desea.

En cuanto a MVC.net, el método para mostrar el HTML es bastante similar. Que en mi opinión es donde terminan las similitudes. Aún necesitarás separar toda tu lógica en el modelo MVC.

Viniendo de ASP y yendo a Web.Form y ahora MVC.Net Puedo decirte que los WebForms fueron un poco molestos/frustrantes de aprender, con el 90% de los tutoriales de MS enseñándote los peores hábitos IE (conexiones SQL en la página, arrastrando conjuntos de datos en los diseñadores). Sin embargo, una vez que pasas, puedes hacer mucho más rápidamente que en asp (paginación o compilar una tabla de datos simple con edición, por ejemplo), pero STILL nunca he visto un gran proyecto de webforms con un n-tier diseño que pensé que era fácil de seguir, implementar y usar.

MVC.NET es como un regalo del cielo. Fuerza los patrones y las prácticas en tu garganta, tiene reglas estrictas a las que se adhiere la mayoría. Permite una fácil cobertura de código y separación de preocupaciones. Después de estar frustrado con los formularios web durante años, finalmente parece que no estoy pirateando las cosas juntas cuando intento hacer algo que no puedo arrastrar fuera de la barra de herramientas.

Personalmente, probaría los formularios web para que sepa cuánto mejor MVC es cuando comience a usarlo.

1

De cualquier manera, siempre es mejor comenzar desde cero e implementar solo la lógica.

Empecé ASP hace mucho tiempo (hace más de 12 años) y solo en 2006 me mudé a ASP.NET 2.0, ni siquiera hoy lo sé todo, pero sí sé más de lo que hago todos los días en el trabajo.

En mi opinión ahora, y volviendo a mi conocimiento de ASP, iría a formularios web en lugar de MVC, primero, es un lenguaje que está en el "mercado" algunos años y muy usado en todo el mundo, mientras MVC todavía está en Beta, entonces, no es adecuado para entornos de producción (dice Microsoft, incluso si este sitio está escrito en MVC).

Tiendo a confundir con el diagrama de MVC, y hay más trucos de los que quiero aprender si necesito hacer un cambio rápido de un proyecto de ASP.

1

Depende. ASP.NET MVC no es una bala de cristal y en muchos sentidos da algunos pasos hacia atrás en términos de productividad del desarrollador.

Si tiene un presupuesto ajustado y necesita hacer esto rápido, creo que ASP.Net es el camino a seguir, ya que tiene la gran cantidad de controles como cuadrículas, paginación, validación, etc. que puede usar de manera inmediata . El uso de estos controles sin duda ahorrará mucho tiempo de desarrollo.Todos estos controles que la mayoría de las personas consideran peatones ahora en ASP.NET deben crearse desde cero o tomarse de Internet cuando utilice el proyecto ASP.NET MVC.

Por otro lado, si tiene el tiempo y el presupuesto ahora y en el futuro, y desea tener una solución que sea sólida como una roca, y se presta más fácilmente al desarrollo impulsado por pruebas, ASP.NET MVC es probablemente el mejor elección.

1

Definitivamente ASP.NET MVC es mejor en términos de estilo. (Dicho esto, no hacer tienen utilizar repetidores y otros controles tontas en una aplicación Web Forms, que puede sólo tiene que utilizar el código en línea al igual que lo haría en MVC.)

MVC en general, sin embargo sería una puerto más fácil, darle una mejor estructura y ser una experiencia más placentera.

-1

ASP.NET MVC es mejor que los formularios web para la prueba automática de unidades de la interfaz de usuario. Sin embargo, las pruebas unitarias automáticas en general son malas prácticas e incluso peores para la UI. La prueba manual es la mejor manera de crear una aplicación de calidad y de hacer el mejor uso del tiempo de desarrollo. Crear pruebas unitarias automatizadas es una pérdida de tiempo y terminas con un código basura para mantener con el código central. A muchos desarrolladores les gustan las pruebas unitarias automatizadas porque creen que son una prueba de que su aplicación funciona, lo cual es falso. También están tratando de evitar el diseño de aplicaciones usando UML, por lo que están usando el desarrollo basado en pruebas para diseñar usando un código que es responsable de las aplicaciones mal diseñadas. Con TDD, estás refabricando el código que escribiste mal sin pensar en el panorama general usando modelos en primer lugar.

Entonces MVC es inútil. Web Forms utiliza un mejor modelo orientado a objetos, mientras que MVC se parece más al ASP clásico de estilo antiguo y a otros patrones de diseño más antiguos. Esto es 2010 y MVC está muerto. Web Forms es como ORM para la interfaz de usuario.

1

Web Forms está más orientado a objetos, mientras que MVC es como ASP clásico en la parte superior del código .NET. El diseño del modelo debe ser el mismo usando Web Forms o MVC. La única diferencia es que Web Forms tiene una abstracción orientada a objetos a la interfaz de usuario y MVC utiliza funciones y fragmentos de código en lugar de clases para organizar el código de la interfaz de usuario.