entre - ¿Migrando ASP clásico-Webforms o ASP.NET MVC?
web forms c# tutorial (10)
Estoy haciendo un 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?
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 de tener que agregar manejo y lógica para ViewState, etc. podría ser un trabajo adicional.
No creo que mi cliente solicite una actualización como esta, así que esto es solo teórico.
Supongamos que este código ASP está escrito muy bien (lo que no siempre es cierto, por supuesto), de modo que realmente la pregunta es si un sitio ASP mejor diseñado para un mejor caso migrará mejor a MVC que WebForms.
(Tenga en cuenta que soy muy nuevo en ASP.NET MVC, por lo que podría perder algo crucial aquí).
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.
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 mirando hacia atrás a mi conocimiento de ASP, iría a Web Forms en lugar de MVC, primero, es un lenguaje que está en el "mercado" algunos años y muy usado en todo el mundo, mientras que MVC todavía está en Beta, por lo tanto, no es adecuado para el entorno de producción (dice Microsoft, incluso si este sitio está escrito en MVC).
Tiendo a confundir el diagrama MVC, y hay más trucos de los que quiero aprender si necesito hacer un cambio rápido de un proyecto ASP.
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 conoces 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 son 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 sitio asp clásico. En cada caso, el sitio es un desastre. La peor parte es que generalmente están llenos de enormes agujeros de seguridad.
Hay más en ASP.NET-MVC 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.
IMO WebForms intenta ocultar html demasiado para mi gusto y puede hacer que su proyecto tarde más de lo que desea debido a la conversión de un montón de html en los controles de formularios web.
Por otro lado, MVC le permite reutilizar parte de esta lógica a la vez que hace que su aplicación sea mucho más fácil de mantener y con el Patrón de Arquitectura apropiado su aplicación puede desarrollarse y refactorizarse mucho más rápido que cualquier proyecto de WebForms.
¡Digo MVC todo el camino!
No creo que uno sea más fácil de convertir que el otro.
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 a MVC.Net puedo decirles que los WebForms fueron un poco molestos / frustrantes de aprender, con el 90% de los tutoriales de MS que le enseñan los peores hábitos IE (conexiones de SQL en la página, arrastrando conjuntos de datos en 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 sepas cuánto mejor es MVC cuando comiences a usarlo.
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 terminarlo rápidamente, creo que ASP.Net es el camino a seguir, ya que cuenta con 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 que se preste más fácilmente al desarrollo impulsado por pruebas, ASP.NET MVC es probablemente la mejor opción.
Definitivamente ASP.NET MVC es mejor en términos de estilo. (Dicho esto, no tienes que usar repetidores y otros controles tontos en una aplicación de WebForms, simplemente puedes usar el código en línea como lo harías en MVC).
Sin embargo, MVC en general sería un puerto más fácil, te daría una mejor estructura y sería una experiencia más placentera.
ASP.NET MVC es mejor que los formularios web para pruebas unitarias automatizadas 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.
Web Forms está más orientado a objetos, mientras que MVC es como ASP clásico sobre el 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.