ihttpactionresult - ¿Debo migrar a ASP.NET MVC?
system web asp net core (20)
No conozco ASP.NET MVC, pero estoy muy familiarizado con el patrón MVC. No veo otra forma de construir aplicaciones profesionales sin MVC. Y tiene que ser MVC modelo 2, como Spring o Struts. Por cierto, ¿cómo estaban construyendo las aplicaciones web sin MVC? Cuando tiene la situación de que es necesario algún tipo de validación en cada solicitud, como validación si el usuario está autenticado, ¿cuál es su solución? ¿Algún tipo de incluir (validate.aspx) en cada página?
¿Nunca has oído hablar del desarrollo N-Tier?
Acabo de escuchar el podcast número 17 del equipo de StackOverflow, y hablaron tan bien de ASP.NET MVC que decidí verificarlo.
Pero primero, quiero estar seguro de que vale la pena. Ya creé una aplicación web base (para que otros desarrolladores la construyan) para un proyecto que se inicia en unos días y quería saber, en función de 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.
¿Hay realmente grandes profesionales que valgan la pena?
EDITAR: No es un proyecto existente, es un proyecto a punto de comenzar, así que si voy a hacerlo debería ser ahora ...
Acabo de encontrar esto
Sin embargo, no utiliza el modelo de postback 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 inquietudes y la capacidad de prueba ( también significa que no hay estado de visualización o ciclo de vida de la página con vistas basadas en MVC ).
¿Cómo funcionaría eso? No viewstate? ¿No hay eventos?
¿El hecho de que ASP.net MVC está solo en ''Vista previa 5'' es motivo de preocupación cuando se investiga?
Sé que se creó al usarlo, pero ¿hay alguna posibilidad de que Microsoft pueda implementar cambios significativos en el framework antes de que esté oficialmente fuera de la versión beta / alpha / preview?
@Jonathan Holland Vi que te rechazaron, pero ese es un punto MUY VÁLIDO. He estado leyendo algunas publicaciones en intertubos donde las personas parecen confundir ASP.NET MVC con el framework y MVC con el patrón .
MVC en sí mismo es un PATRÓN DE DISEÑO . Si todo lo que está buscando es una "separación de preocupaciones", entonces puede lograrlo con 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 margen de beneficio en el mundo ASP.NET, entonces MVC the ramework es para usted.
@Juan Manuel ¿Alguna vez trabajaste en ASP clásico? ¿Cuándo tuvo que programar todos sus propios eventos y elementos de "viewstatish" (como un menú desplegable que recuerda su valor seleccionado después del envío del formulario)?
Si es así, entonces ASP.NET MVC no se sentirá tan incómodo. Verificaría la "Serie MVC Storefront " de Rob Conery''s Awesome, donde ha estado revisando el marco y creando cada componente esperado para un sitio de escaparate. Es realmente impresionante y fácil de seguir (ponerse al día es difícil porque Rob ha estado realmente activo y publicó MUCHO en esa serie).
Personalmente, y bastante contrario a los sentimientos de Jeff Atwood sobre el tema , prefiero el modelo de formulario web. Era totalmente diferente a los días de vbscript / ASP clásico sin duda, pero mantener Viewstate bajo control y escribir sus propios controles amigables CSS fue agradable, en realidad.
Por otra parte, tenga en cuenta que dije "me gustó". ASP.NET MVC es realmente asombroso y más parecido a otras tecnologías web. Ciertamente, es más fácil pasar de ASP.NET MVC a RAILS si le gusta o necesita trabajar en múltiples plataformas. Y mientras, sí, es muy estable obviamente (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.
A menos que los desarrolladores con los que está trabajando estén familiarizados con el patrón MVC, no lo haría. Como mínimo, hablaría con ellos antes de hacer un cambio tan grande.
Es importante tener en cuenta que MVC y WebForms no compiten, y que uno no es mejor que el otro. Simplemente son herramientas diferentes. La mayoría de las personas parece acercarse a MVC vs WebForms ya que "uno debe ser un mejor martillo que el otro". Eso está mal. Uno es un martillo, el otro es un destornillador. Ambos se usan en el proceso de poner las cosas juntas, pero tienen diferentes fortalezas y debilidades.
Si uno lo dejó con un mal sabor, probablemente estaba tratando de usar un destornillador para golpear un clavo. Ciertos problemas son engorrosos con WebForms que se vuelven elegantes y simples con MVC, y viceversa.
He usado ASP.NET MVC (incluso escribí un HTTPModule que te permite definir las rutas en web.config), y todavía tengo un sabor amargo en mi boca al respecto.
Parece un gran paso atrás en la organización y la productividad. Tal vez no sea para algunos, pero tengo formas web resueltas, y no presentan ningún desafío para que puedan mantenerse.
Eso, y no apruebo la moda actual de "PRUEBA TODO" ...
No conozco ASP.NET MVC, pero estoy muy familiarizado con el patrón MVC. No veo otra forma de construir aplicaciones profesionales sin MVC. Y tiene que ser MVC modelo 2, como Spring o Struts. Por cierto, ¿cómo estaban construyendo las aplicaciones web sin MVC? Cuando tiene la situación de que es necesario algún tipo de validación en cada solicitud, como validación si el usuario está autenticado, ¿cuál es su solución? ¿Algún tipo de incluir (validate.aspx) en cada página?
No recomendaría simplemente hacer el cambio en un proyecto existente. Quizás inicie un pequeño proyecto de "demostración" que el equipo pueda usar para experimentar con la tecnología y (si es necesario) aprenda lo que necesita y demuestre a la gerencia que vale la pena realizar el cambio. Al final, incluso el equipo de desarrollo podría darse cuenta de que no están listos o que no vale la pena.
Hagas lo que hagas, asegúrate de documentarlo. Quizás si usa un proyecto de demostración, escriba una autopsia para referencia futura.
No, no deberías. No dude en probarlo en un nuevo proyecto, pero mucha gente familiarizada con los formularios web de ASP.NET aún no lo ama, debido a que tiene que rebuscar en HTML sin procesar + muchos conceptos diferentes + selecciones bastante delgadas en la documentación / tutoriales.
Primero crearía un sitio de prueba y vería lo que piensa el equipo, pero para mí no volvería a utilizar 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 sobre cosas como el ciclo de vida de la página, renderizando HTML y biggy para mí, sin viewstate cruft incrustado en la fuente de la página.
Algunas personas prefieren MVC para una mejor prueba, pero personalmente la mayor parte de mi código está en la capa intermedia y se prueba fácilmente de todos modos ...
ASP.NET MVC básicamente le permite separar la responsabilidad de las diferentes secciones del código. Esto le permite probar su aplicación. Puede probar sus Vistas, Rutas, etc. También acelera la aplicación ya que ahora no hay ViewState o Postback.
PERO, también hay desventajas. Como no utiliza WebForms, no puede usar ningún control ASP.NET. Significa que si quieres crear un GridView estarás ejecutando un ciclo for y crearás la tabla manualmente. Si desea utilizar el Asistente de ASP.NET en MVC, tendrá que crear por su cuenta.
Es un buen marco si está cansado y enfermo del formulario web de ASP.NET y desea realizar todo por su cuenta. Pero debes tener en cuenta que te beneficiarías al crear todas las cosas nuevamente o no?
En general, prefiero el framework Webforms debido a la gran cantidad de controles y la instalación automática de tuberías.
Si está satisfecho con WebForms hoy, entonces ASP.NET MVC no es para usted.
Me he sentido frustrado con WebForms durante mucho tiempo. Definitivamente no estoy solo aquí. La abstracción de estado inteligente de cliente inteligente a través de la web se rompe severamente en escenarios complejos. Me encantan los HTML, Javascript y CSS. WebForms intenta ocultar eso de mí. También tiene algunas soluciones realmente complejas para problemas que realmente no son tan complejos. Webforms también es intrínsecamente difícil de probar, y si bien puede usar MVP, no es una gran solución para un entorno web ... (en comparación con MVC).
MVC le gustará si ... - desea más control sobre su HTML - desea una experiencia ajax sin problemas como cualquier otra plataforma lo tiene - quiere testabilidad de principio a fin - quiere URL significativas - HATE trata con problemas de devolución de datos y estado de visualización
Y en cuanto al marco que es Vista previa 5, es bastante estable, el diseño está principalmente allí, y la actualización no es difícil. Inicié una aplicación en la Vista previa 1 y me actualicé a las pocas horas de que esté disponible la vista previa más reciente.
Si usted es un desarrollador profesional de ASP.NET, y tiene algo de tiempo de sobra para aprender cosas nuevas, ciertamente le recomendaría que pase algún tiempo probando 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 webform tradicional, pero al tratar de descubrir MVC, seguramente aprenderá mucho, y podría generar muchas ideas que puedes postularte en tu trabajo
Una cosa buena que noté mientras revisaba muchas publicaciones de blogs y videos tutoriales mientras trataba de desarrollar un proyecto de mascotas 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 una gran cantidad de 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 estuve expuesto con tanta profundidad antes.
La forma de hacer ASP.NET MVC es tan diferente de las formas web que te hará temblar un poco la mente, ¡y eso para un desarrollador es muy bueno!
OTOH para principiantes 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 está más cerca de la forma en que realmente funciona la web (HTML es sin estado, después de todo). En MVC usted decide en cada byte que va y viene en el cable (al menos mientras no se vuelve loco con los ayudantes html). Una vez que el tipo lo consigue, estará mejor equipado para moverse a las instalaciones "artificiales" provistas por los formularios web ASP.NET y los controles del servidor.
Si no está seguro de usar un framework MVC, entonces prefiero usar uno de los proyectos de Castle ...
Cuando eso se dice, personalmente creo que WebControls tiene muchas ventajas, como por ejemplo la posibilidad de crear aplicaciones basadas en eventos que tienen un cliente con estado, etc. La mayoría de los argumentos en contra de WebControls están construidos debido a la falta de comprensión del modelo de WebControl, etc. Y no porque realmente sean realmente malos ...
MVC no es un Silver Bullet, especialmente no Microsoft MVC ...
Si le gusta usar controles de servidor que hacen mucho trabajo para usted, NO le gustará MVC porque necesitará hacer mucha codificación de mano en MVC. Si te gusta el GridView, espera escribir uno tú mismo o usar el de otra persona.
MVC no es para todos, especialmente si no está en la unidad de prueba de la parte de la GUI. Si te sientes cómodo con los formularios web, quédate con eso. Web Forms 4.0 solucionará algunas de las deficiencias actuales, como las identificaciones asignadas automáticamente por ASP.NET. Usted tendrá el control de estos en la próxima versión.
He visto algunas implementaciones del framework MVC donde, por el bien de la capacidad de prueba, alguien procesaba todo el código HTML. En este caso, la vista también es un código comprobable. Pero dije, amigo mío, poner HTML en el código es una pesadilla de mantenimiento y dijo que me gusta todo compilado y probado. No discutí, pero más tarde descubrí que puso este HTML en los archivos de recursos y la locura continuó ...
Poco se dio cuenta de que la idea de separar View también resolvió la parte de mantenimiento. Sobrepasa la capacidad de prueba en algunas aplicaciones. No es necesario que probemos el diseño HTML si estamos usando la herramienta WYSWYG. Los WebForms son buenos por esa razón.
A menudo he visto personas abusando de la postback y viewstate y culpándola del modelo ASP .NET.
Recuerde que las mejores páginas web siguen siendo .HTMLs y ahí está el poder de ASP .NET MVC.
Ajax, RAD (formularios web con ajax son anti-RAD muy a menudo), CONTROL COMPLETO (sin desarrollar un montón de código y ciclos). los formularios web son buenos solo para enlazar una grilla y cosas así, y no para nada más, y una cosa más importante: el rendimiento. cuando te atascas en los formularios web, antes o después, activarás MVC.
Estoy tratando de tomar esa misma decisión sobre ASP.NET MVC, Juan Manuel . Ahora estoy esperando que llegue el proyecto correcto del tamaño de un bocado con el que puedo experimentar. Si el experimento va bien, mi intuición dice que sí, entonces voy a diseñar mis nuevos proyectos grandes en el marco.
Con ASP.NET MVC, usted pierde el modelo viewstate / postback de ASP.NET Web Forms. Sin esa abstracción, trabajas mucho más de cerca con los comandos HTML y HTTP POST y GET. Creo que la programación de la interfaz de usuario está algo en la dirección del ASP clásico.
Con ese inconveniente, viene un mayor grado de control. Con mucha frecuencia me he encontrado luchando contra la basura de sesión psuedo de ASP.NET y la perspectiva de recuperar el control completo del HTML de salida parece muy refrescante.
Quizás sea el mejor - o el peor - de ambos mundos.