Pregunta

Acabo de escuchar el podcast número 17 del equipo de StackOverflow y hablaron muy bien de ASP.NETMVC que decidí comprobarlo.

Pero primero quiero estar seguro de que vale la pena.Ya creé una aplicación web base (para que otros desarrolladores puedan desarrollarla) para un proyecto que comenzará en unos días y quería saber, según su experiencia, si debería tomarme el tiempo para aprender los conceptos básicos de MVC y volver a crear. la aplicación web base con este modelo.

¿Existen realmente grandes ventajas que harían que valga la pena?

EDITAR:No es un proyecto existente, es un proyecto por comenzar, así que si voy a hacerlo debería ser ahora...


acabo de encontrar esto

Sin embargo, no utiliza el modelo de devolución de datos existente para las interacciones con el servidor.En su lugar, enrutará todas las interacciones del usuario final a una clase de Controlador, lo que ayuda a garantizar una separación clara de las preocupaciones y la capacidad de prueba (También significa que no hay estado de visualización ni ciclo de vida de la página con vistas basadas en MVC.).

¿Cómo funcionaría eso?¿Sin estado de visualización?¿No hay eventos?

¿Fue útil?

Solución

Si está bastante satisfecho con WebForms hoy en día, tal vez ASP.NET MVC no sea para usted.

He estado frustrado con WebForms durante mucho tiempo.Definitivamente no estoy solo aquí.La abstracción con estado y cliente inteligente en la web falla gravemente en escenarios complejos.Resulta que me encanta HTML, Javascript y CSS.WebForms intenta ocultármelo.También tiene algunas soluciones realmente complejas a problemas que en realidad no lo son tanto.Los formularios web también son intrínsecamente difíciles de probar y, si bien puedes usar MVP, no es una gran solución para un entorno web... (en comparación con MVC).

MVC le resultará atractivo si...- Desea más control sobre su HTML - quiere una experiencia de Ajax perfecta como cualquier otra plataforma - quiere la capacidad de prueba a través de las URL significativas - Odio lidiar con la respuesta y los problemas de ViewState

Y en cuanto a que el marco es la Vista previa 5, es bastante estable, el diseño está prácticamente ahí y la actualización no es difícil.Inicié una aplicación en la Vista previa 1 y la actualicé a las pocas horas de estar disponible la vista previa más reciente.

Otros consejos

Es importante tener en cuenta que MVC y WebForms no compiten y uno no es mejor que el otro.Son simplemente herramientas diferentes.La mayoría de la gente parece abordar MVC vs WebForms como "uno debe ser mejor martillo que el otro".Eso está mal.Uno es un martillo y el otro es un destornillador.Ambos se utilizan en el proceso de armar cosas, pero tienen diferentes fortalezas y debilidades.

Si uno te dejó con mal sabor de boca, probablemente estabas tratando de usar un destornillador para clavar un clavo.Ciertos problemas son engorrosos con los WebForms que se vuelven elegantes y simples con MVC, y viceversa.

He usado ASP.NET MVC (incluso escribí un módulo HTTP que te permite definir las rutas en web.config) y todavía tengo un sabor amargo en la boca.

Parece un paso de gigante hacia atrás en organización y productividad.Tal vez no sea para algunos, pero tengo los formularios web resueltos y no representan ningún desafío para mí en cuanto a hacerlos mantenibles.

Eso, y no respaldo la moda actual de "PRUEBA TODO"...

ASP.NET MVC básicamente le permite separar la responsabilidad de diferentes secciones del código.Esto le permitirá probar su aplicación.Puede probar sus vistas, rutas, etc.También acelera la aplicación ya que ahora no hay ViewState ni Postback.

PERO, también hay desventajas.Dado que no utiliza WebForms, no puede utilizar ningún control ASP.NET.Significa que si desea crear un GridView, ejecutará un bucle for y creará la tabla manualmente.Si desea utilizar el asistente ASP.NET en MVC, tendrá que crearlo usted mismo.

Es un buen marco si está cansado del formulario web ASP.NET y desea realizar todo por su cuenta.Pero debes tener en cuenta si ¿te beneficiaría crear todo el material nuevamente o no?

En general, prefiero el marco Webforms debido al rico conjunto de controles y la plomería automática.

Primero crearía un sitio de prueba y vería qué piensa el equipo, pero en mi caso no volvería a WebForms después de usar MVC.

A algunas personas no les gusta el código mezclado con HTML, y puedo entenderlo, pero prefiero la flexibilidad a cosas como el ciclo de vida de la página, que representa HTML y es grande para mí: sin estado de visualización incrustado en la fuente de la página.

Algunas personas prefieren MVC para una mejor capacidad de prueba, pero personalmente la mayor parte de mi código está en la capa intermedia y se puede probar fácilmente de todos modos...

@Jonathan Holland Vi que fuiste rechazado, pero ese es un punto MUY VÁLIDO.He estado leyendo algunas publicaciones sobre intertubes donde la gente parece estar confundiendo ASP.NET MVC el marco y MVC el patrón.

MVC en sí mismo es un PATRÓN DE DISEÑO.Si lo único que busca es una "separación de preocupaciones", entonces ciertamente puede lograrlo con los formularios web.Personalmente soy un gran admirador del Patrón MVP en un entorno estándar de n niveles.

Si realmente desea un control TOTAL de su marcado en el mundo ASP.NET, entonces MVC el marco es para usted.

@Juan Manuel ¿Alguna vez trabajaste en ASP clásico?¿Cuándo tuvo que programar todos sus propios eventos y elementos "viewstatish" (como un menú desplegable que recuerda el valor seleccionado después del envío del formulario)?

Si es así, entonces ASP.NET MVC no se sentirá tan incómodo desde el principio.Me gustaría ver la impresionante serie de Rob Conery "Escaparate de MVC" donde ha estado recorriendo el marco y construyendo cada componente esperado para el sitio de una tienda.Es realmente impresionante y fácil de seguir (ponerse al día es difícil porque Rob ha estado muy activo y ha publicado MUCHO en esa serie).

Personalmente, y muy al contrario de lo que dice Jeff Atwood sentimientos sobre el tema, Me gustó bastante el modelo de formulario web.Sin duda, era totalmente diferente a los días de vbscript/ASP clásico, pero mantener el estado de visualización bajo control y escribir sus propios controles compatibles con CSS fue divertido, en realidad.

Por otra parte, tenga en cuenta que dije "me gustó".ASP.NET MVC es realmente asombroso y se parece más a otras tecnologías web que existen.Ciertamente es más fácil pasar de ASP.NET MVC a RAILS si desea o necesita trabajar en múltiples plataformas.Y aunque sí, obviamente es muy estable (este mismo sitio), si su empresa no permite el software "beta" de cualquier color;implementarlo en producción en este momento podría ser un problema.

Si es un desarrollador profesional de ASP.NET y tiene algo de tiempo libre para aprender cosas nuevas, sin duda le recomendaría que dedique algún tiempo a probar ASP.NET MVC.Puede que no sea la solución a todos sus problemas y hay muchos proyectos que pueden beneficiarse más de una implementación de formulario web tradicional, pero al intentar descubrir MVC seguramente aprenderá mucho y podría generar muchas ideas que puedes aplicar en tu trabajo.

Una cosa buena que noté al leer muchas publicaciones de blog y tutoriales en video mientras intentaba desarrollar un proyecto mascota MVC es que la mayoría de ellos siguen las mejores prácticas actuales (TDD, IoC, inyección de dependencia y, en menor medida, POCO). además de mucho JQuery para hacer que la experiencia sea más interesante para el usuario, y eso es algo que puedo aplicar en mis aplicaciones de formularios web actuales y que no había expuesto con tanta profundidad antes.

La forma de hacer las cosas de ASP.NET MVC es tan diferente de los formularios web que te sacudirá un poco, ¡y eso para un desarrollador es muy bueno!

OTOH para un principiante total en el desarrollo web, creo que MVC es definitivamente un mejor comienzo porque ofrece un buen patrón de diseño listo para usar y se acerca más a la forma en que realmente funciona la web (después de todo, HTML no tiene estado).En MVC, usted decide cada byte que va y viene en el cable (al menos mientras no se vuelva loco con los asistentes html).Una vez que el chico entienda eso, estará mejor equipado para pasar a las instalaciones "artificiales" proporcionadas por los formularios web y controles del servidor ASP.NET.

Si le gusta utilizar controles de servidor que hacen mucho trabajo por usted, NO le gustará MVC porque necesitará realizar mucha codificación manual en MVC.Si le gusta GridView, espere escribir uno usted mismo o utilizar el de otra persona.

MVC no es para todos, especialmente si no te gustan las pruebas unitarias de la parte GUI.Si se siente cómodo con los formularios web, quédese con ellos.Web Forms 4.0 solucionará algunas de las deficiencias actuales, como las ID que ASP.NET asigna automáticamente.Tendrás el control de estos en la próxima versión.

A menos que los desarrolladores con los que está trabajando estén familiarizados con el patrón MVC, yo no lo haría.Como mínimo, hablaría con ellos primero antes de hacer un cambio tan grande.

Estoy intentando tomar la misma decisión sobre ASP.NET MVC, Juan Manuel.Ahora estoy esperando que llegue el proyecto del tamaño de un bocado adecuado con el que pueda experimentar.Si el experimento sale bien (mi instinto me dice que así será), entonces diseñaré mis nuevos grandes proyectos en torno a ese marco.

Con ASP.NET MVC se pierde el modelo de estado de visualización/devolución de datos de ASP.NET Web Forms.Sin esa abstracción, se trabaja mucho más estrechamente con el HTML y los comandos HTTP POST y GET.Creo que la programación de la interfaz de usuario va en cierta medida en la dirección del ASP clásico.

Ese inconveniente conlleva un mayor grado de control.Muy a menudo me he encontrado luchando contra la basura de pseudosesiones de ASP.NET y la perspectiva de recuperar el control total del HTML de salida parece muy refrescante.

Quizás sea lo mejor (o lo peor) de ambos mundos.

No conozco ASP.NET MVC, pero estoy muy familiarizado con el patrón MVC.No veo otra forma de crear aplicaciones profesionales sin MVC.Y tiene que ser MVC modelo 2, como Spring o Struts.Por cierto, ¿cómo creaban aplicaciones web sin MVC?Cuando se encuentra en una situación en la que es necesario algún tipo de validación en cada solicitud, como validar si el usuario está autenticado, ¿cuál es su solución?¿Algún tipo de inclusión (validar.aspx) en cada página?

¿Nunca has oído hablar del desarrollo de N-Tier?

Ajax, RAD (los formularios web con ajax son anti-RAD muy a menudo), CONTROL COMPLETO (sin desarrollar una gran cantidad de código y ciclos).Los formularios web solo sirven para vincular alguna cuadrícula y demás, y no para nada más, y una cosa más realmente importante: el rendimiento.Cuando te quedas atascado en los formularios web, tarde o temprano activarás MVC.

No recomendaría simplemente hacer el cambio en un proyecto existente.Tal vez inicie un pequeño proyecto de "demostración" que el equipo pueda utilizar para experimentar con la tecnología y (si es necesario) aprender lo que necesitan y demostrar a la gerencia que vale la pena hacer el cambio.Al final, incluso el equipo de desarrollo podría darse cuenta de que no están preparados o que no merece la pena.

Hagas lo que hagas, asegúrate de documentarlo.Quizás, si utiliza un proyecto de demostración, escriba una autopsia para referencia futura.

No conozco ASP.NET MVC, pero estoy muy familiarizado con el patrón MVC.No veo otra forma de crear aplicaciones profesionales sin MVC.Y tiene que ser MVC modelo 2, como Spring o Struts.Por cierto, ¿cómo creaban aplicaciones web sin MVC?Cuando se encuentra en una situación en la que es necesario algún tipo de validación en cada solicitud, como validar si el usuario está autenticado, ¿cuál es su solución?¿Algún tipo de inclusión (validar.aspx) en cada página?

No, no deberías.Siéntase libre de probarlo en un nuevo proyecto, pero a muchas personas familiarizadas con los formularios web ASP.NET aún no les gusta, debido a que tienen que trastear con HTML sin formato + muchos conceptos diferentes + selecciones bastante escasas en documentación/ tutoriales.

¿El hecho de que ASP.net MVC solo esté en la 'Vista previa 5' es motivo de preocupación al investigarlo?

Sé que StackOverflow se creó usándolo, pero ¿existe la posibilidad de que Microsoft pueda implementar cambios significativos en el marco antes de que salga oficialmente de la versión beta/alfa/preview?

Si está decidido a utilizar un marco MVC, entonces preferiría utilizar el del proyecto Castle...

Dicho esto, personalmente creo que los WebControls tienen muchas ventajas, como por ejemplo poder crear aplicaciones controladas por eventos que tienen un cliente con estado, etc.La mayoría de los argumentos en contra de WebControls se construyen debido a la falta de comprensión del modelo WebControl, etc.Y no porque en realidad sean realmente malos...

MVC no es una solución milagrosa, especialmente Microsoft MVC...

He visto alguna implementación del marco MVC donde, por razones de capacidad de prueba, alguien representó todo el HTML en código.En este caso, la vista también es un código comprobable.Pero le dije, amigo mío, poner HTML en el código es una pesadilla de mantenimiento y él dijo, bueno, me gusta todo lo compilado y probado.No discutí, pero luego descubrí que puso este HTML en archivos de recursos y la locura continuó...

No se dio cuenta de que la idea de separar View también resolvió la parte de mantenimiento.Supera la capacidad de prueba en algunas aplicaciones.No necesitamos probar el diseño HTML si utilizamos la herramienta WYSWYG.Los WebForms son buenos por ese motivo.

A menudo he visto personas abusando de la devolución de datos y del estado de visualización y culpando al modelo ASP .NET.

Recuerde que las mejores páginas web siguen siendo .HTML y ahí es donde está el poder de ASP .NET MVC.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top