none
MVC vs WebForms

    Pregunta

  • ¿Por qué parece que TDD es perfecto para MVC cuando todos hemos trabajado con webforms desacoplando la lógica de negocio (BLL) y haciendola perfectamente testeable? No entiendo este factor en contra de WebForms.

     

    De acuerdo, el menejo de viewstates en WebForms es tedioso. Es más, es inevitable dejarnos viewstates habilitados en controles que ni lo requieren. En especial cuando se usan UpdatePanels donde las actualizaciones parciales no afectan a otras áreas de la página.

    Esta desventaja de los viewstates, a mi parecer, se mejora de modo sobresaliente en la nueva versión del framework (4.0) permitiéndonos un control exacto de aquello de lo que queremos mantener su estado.

     

    No tengo experiencia profesional con MVC pero la sensación que me da es que solo sirve para hacer aplicaciones poco llamativas donde el  maestro y el detalle residen en páginas diferentes. Del mismo modo, hacer un wizard se vuelve impracticable si no es con el uso del objeto sesión.

    Mirando mis aplicaciones realizadas a la fecha, son abundantes las situaciones en las que necesito hacer postbacks con ánimo de mostrar nuevos controles u ocultar otros, pues estos comportamientos rigen el workflow de mi aplicación.

     

    De corazón mi proposito no es atacar MVC pero tengo que adapatarme a él, y creedme que tengo mis dudas, así que os pregunto:

    Vostros, que ya venís haciendo aplicaciones de buena apariencia en webforms,

    1. ¿Realmente os ha alegrado la vida MVC?
    2. ¿Escogeríais MVC en vuestro próximo proyecto empresarial?
    3. Pregunta mas extrema: ¿Es de locos hacer una web pública en WebForms?

    Gracias de antemano,  espero que me echeis un cable para seguir por el camino de MVC o de lo contrario aconsejadme quedarme en el mundo poco purista, pero eficiente, de WebForms.

    domingo, 30 de mayo de 2010 20:07

Respuestas

  • Hola, César.

    Apunto rápidamente mis opiniones sobre cada una de las cuestiones que comentas.

    >¿Por qué parece que TDD es perfecto para MVC cuando todos hemos trabajado con webforms desacoplando la lógica de negocio (BLL) y haciendola perfectamente testeable? No entiendo este factor en contra de WebForms.

    Una lógica de negocio bien aislada es igualmente válida y beneficiosa para tests unitarios en ambas tecnologías. Aunque webforms no favorece especialmente el hacerlo así, es cierto que muchos hemos trabajado de esta forma, facilitando la limpieza y la realización de pruebas sobre la lógica de negocio (el "Modelo" en MVC).

    El framework MVC permite ir un paso más allá simplificando enormemente la realización de pruebas (o aplicar TDD) también en la lógica de control y flujo de ejecución; el equivalente en Webforms sería algo así como hacer testing sobre el code-behind, que como sabrás, no es una tarea nada sencilla (o a veces simplemente imposible). 

    >De acuerdo, el menejo de viewstates en WebForms es tedioso. Es más, es inevitable dejarnos viewstates habilitados en controles que ni lo requieren. En especial cuando se usan UpdatePanels donde las actualizaciones parciales no afectan a otras áreas de la página. Esta desventaja de los viewstates, a mi parecer, se mejora de modo sobresaliente en la nueva versión del framework (4.0) permitiéndonos un control exacto de aquello de lo que queremos mantener su estado.

    Efectivamente, el control del ViewState ha mejorado mucho con ASP.NET 4. También se ha abierto ahora a Webforms el routing y la capacidad de utilizar "friendly URLs", que era antes exclusivo de MVC, y la generación de código de los controles es más acertada. Todo esto es positivo, e indica que la tecnología sigue evolucionando hacia mejor.

    Sin embargo, en lo relativo al ViewState, el fondo sigue siendo el mismo. Aunque sólo lo activemos en controles "elegidos",  continuaremos añadiendo a las páginas una mochila a veces demasiado pesada.

    Además, el problema del ViewState no es únicamente el coste en cuanto a pérdida de control, ancho de banda o mayor consumo de tiempo de proceso de las peticiones. No olvidemos que el objetivo del ViewState, eventos y postbacks es crear una abstracción al desarrollador y hacerle ver que no está trabajando para la web, que está ante un entorno conectado y con mantenimiento de estado, como puede ser un formulario Windows. Y dado que estamos trabajando para la web, este alejamiento de la realidad no es buena cosa.

    En cuanto a los UpdatePanels... uff... me mantengo alejado de ellos desde que comprobé cómo funcionan...

    >No tengo experiencia profesional con MVC pero la sensación que me da es que solo sirve para hacer aplicaciones poco llamativas donde el  maestro y el detalle residen en páginas diferentes.

    En absoluto. Las aplicaciones creadas con MVC pueden ser bastante espectaculares, tanto como quiera/pueda el desarrollador. Además, suelen serlo gracias a la facilidad de integración con Ajax, librerías como jQuery, y sus cientos de plugins.

    Pero no dudes que podemos hacer aplicaciones llamativas y poco llamativas con MVC... y con Webforms, y con RoR, y con Struts... Al fin y al cabo, al final sólo estamos generando html, css y scripts, y con esta combinación de elementos puede salir casi cualquier cosa ;-)

    Por último: créeme, con MVC también puedes tener el maestro y el detalle en la misma página. :-)

    >Del mismo modo, hacer un wizard se vuelve impracticable si no es con el uso del objeto sesión.

    No necesariamente. Es perfectamente viable hacer un wizard sin usar los Session en MVC, al igual que en Webforms.

    La cuestión consiste simplemente en almacenar la información que necesitamos conservar entre los distintos pasos utilizando los medios suministrados por el protocolo (como datos post o el querystring). Básicamente es lo mismo que consigue automágicamente el ViewState, pero controlando nosotros lo que queremos mantener y de qué forma lo hacemos.

    >Mirando mis aplicaciones realizadas a la fecha, son abundantes las situaciones en las que necesito hacer postbacks con ánimo de mostrar nuevos controles u ocultar otros, pues estos comportamientos rigen el workflow de mi aplicación.

    Bueno, el hecho de que en MVC no exista el mantenimiento de estado automático y los eventos no significa que no puedas conseguir lo mismo… 

    En escenarios simples que atañen únicamente a la presentación, pueden (incluso diría "deben”) solucionarse en cliente. Por ejemplo, si tenemos en un formulario un checkbox de cuyo estado depende la visualización de una sección del mismo (“quiero pagar por banco” –> datos bancarios), es algo que con un poco de scripting puede solucionarse sin tener que forzar un envío al servidor.

    Si es algo más profundo y el escenario requiere envío de información al servidor, es igualmente sencillo. Sólo hay que recordar que un postback básicamente no es más que un envío al servidor del formulario completo y una devolución del mismo manteniendo los valores de los campos. Y por supuesto esto puedes hacerlo muy fácilmente con el framework MVC.

    Eso sí, en ASP.NET MVC se promueve la separación de funcionalidades como medio para facilitar el mantenimiento y testeo de componentes. Es decir, se intenta evitar la creación de elementos mastodónticos, con múltiples funciones y responsabilidades, tan habituales de los webforms.

    Off-topic: aprovecho para comentar que, emho, los postbacks para recargar el formulario son un mecanismo para el programador y no para el usuario. Es decir, nos facilitan la vida enormemente a los desarrolladores, pero desde el punto de vista de la usabilidad son una auténtica aberración: rompen la interacción y despistan al usuario. Si has utilizado un formulario pesado con varios postbacks en una red no demasiado rápida seguro que sabes a lo que me refiero. Aunque a veces no hay más remedio, intento evitarlos al máximo y siempre que puedo los sustituyo por código en script (usando javascript puro y duro, MS Ajax, jQuery o lo que sea), ya sea en MVC o en Webforms.

    > ¿Realmente os ha alegrado la vida MVC?
    Hombre, para alegrarte la vida hay muchas cosas mejores que MVC, te lo aseguro ;-)

    Bueno, aunque la frase está algo manida, es cierto que MVC ha traído un poco de aire fresco al desarrollo web para ASP.NET. A los que nos gusta trabajar pegados al protocolo y controlando lo que ocurre, nos ha devuelto la capacidad de hacerlo, y la sensación de tener de nuevo las riendas bien sujetas; para los fans de las pruebas, aporta mucha facilidad y flexibilidad para hacerlo; para los defensores de los estándares, la posibilidad de generar nuestro propio código, sin aditivos ni colorantes; para los seguidores de las aplicaciones al estilo 2.0, una vía sencilla para implementar Ajax y scripting por doquier… en fin, casi a todo el mundo le aporta algo ;-)

    > ¿Escogeríais MVC en vuestro próximo proyecto empresarial?
    Depende. En mi opinión no se puede generalizar, hay muchos factores a tener en cuenta ante una decisión así. Para no repetirme, en http://www.variablenotfound.com/2010/05/aspnet-mvc-2-quince-cuestiones-que.html#p7 he recogido mis reflexiones al respecto.

    De todas formas, hace tiempo comentaban los propios creadores del framework, y lo que he observado hasta el momento así lo demuestra, que “ASP.NET MVC no era para todos, ni para todo”.

    > Pregunta mas extrema: ¿Es de locos hacer una web pública en WebForms?
    No. Durante muchos años lo hemos hecho y seguro que seguiremos haciéndolo. Simplemente, los desarrolladores ASP.NET tenemos una nueva y magnífica alternativa para crear sistemas para la web.

    >Gracias de antemano,  espero que me echeis un cable para seguir por el camino de MVC o de lo contrario aconsejadme quedarme en el mundo poco purista, pero eficiente, de WebForms.

    Desde mi punto de vista, ASP.NET MVC es algo que vale la pena estudiar para, llegado el momento, decidir con conocimiento de causa qué tecnología conviene aplicar en cada caso. Si no lo conoces nunca sabrás si te pierdes algo ;-)

    Suerte :-)


    José M. Aguilar
    Variable not found
    • Marcado como respuesta César. _ lunes, 31 de mayo de 2010 18:10
    lunes, 31 de mayo de 2010 15:58

Todas las respuestas

  • Hola, César.

    Apunto rápidamente mis opiniones sobre cada una de las cuestiones que comentas.

    >¿Por qué parece que TDD es perfecto para MVC cuando todos hemos trabajado con webforms desacoplando la lógica de negocio (BLL) y haciendola perfectamente testeable? No entiendo este factor en contra de WebForms.

    Una lógica de negocio bien aislada es igualmente válida y beneficiosa para tests unitarios en ambas tecnologías. Aunque webforms no favorece especialmente el hacerlo así, es cierto que muchos hemos trabajado de esta forma, facilitando la limpieza y la realización de pruebas sobre la lógica de negocio (el "Modelo" en MVC).

    El framework MVC permite ir un paso más allá simplificando enormemente la realización de pruebas (o aplicar TDD) también en la lógica de control y flujo de ejecución; el equivalente en Webforms sería algo así como hacer testing sobre el code-behind, que como sabrás, no es una tarea nada sencilla (o a veces simplemente imposible). 

    >De acuerdo, el menejo de viewstates en WebForms es tedioso. Es más, es inevitable dejarnos viewstates habilitados en controles que ni lo requieren. En especial cuando se usan UpdatePanels donde las actualizaciones parciales no afectan a otras áreas de la página. Esta desventaja de los viewstates, a mi parecer, se mejora de modo sobresaliente en la nueva versión del framework (4.0) permitiéndonos un control exacto de aquello de lo que queremos mantener su estado.

    Efectivamente, el control del ViewState ha mejorado mucho con ASP.NET 4. También se ha abierto ahora a Webforms el routing y la capacidad de utilizar "friendly URLs", que era antes exclusivo de MVC, y la generación de código de los controles es más acertada. Todo esto es positivo, e indica que la tecnología sigue evolucionando hacia mejor.

    Sin embargo, en lo relativo al ViewState, el fondo sigue siendo el mismo. Aunque sólo lo activemos en controles "elegidos",  continuaremos añadiendo a las páginas una mochila a veces demasiado pesada.

    Además, el problema del ViewState no es únicamente el coste en cuanto a pérdida de control, ancho de banda o mayor consumo de tiempo de proceso de las peticiones. No olvidemos que el objetivo del ViewState, eventos y postbacks es crear una abstracción al desarrollador y hacerle ver que no está trabajando para la web, que está ante un entorno conectado y con mantenimiento de estado, como puede ser un formulario Windows. Y dado que estamos trabajando para la web, este alejamiento de la realidad no es buena cosa.

    En cuanto a los UpdatePanels... uff... me mantengo alejado de ellos desde que comprobé cómo funcionan...

    >No tengo experiencia profesional con MVC pero la sensación que me da es que solo sirve para hacer aplicaciones poco llamativas donde el  maestro y el detalle residen en páginas diferentes.

    En absoluto. Las aplicaciones creadas con MVC pueden ser bastante espectaculares, tanto como quiera/pueda el desarrollador. Además, suelen serlo gracias a la facilidad de integración con Ajax, librerías como jQuery, y sus cientos de plugins.

    Pero no dudes que podemos hacer aplicaciones llamativas y poco llamativas con MVC... y con Webforms, y con RoR, y con Struts... Al fin y al cabo, al final sólo estamos generando html, css y scripts, y con esta combinación de elementos puede salir casi cualquier cosa ;-)

    Por último: créeme, con MVC también puedes tener el maestro y el detalle en la misma página. :-)

    >Del mismo modo, hacer un wizard se vuelve impracticable si no es con el uso del objeto sesión.

    No necesariamente. Es perfectamente viable hacer un wizard sin usar los Session en MVC, al igual que en Webforms.

    La cuestión consiste simplemente en almacenar la información que necesitamos conservar entre los distintos pasos utilizando los medios suministrados por el protocolo (como datos post o el querystring). Básicamente es lo mismo que consigue automágicamente el ViewState, pero controlando nosotros lo que queremos mantener y de qué forma lo hacemos.

    >Mirando mis aplicaciones realizadas a la fecha, son abundantes las situaciones en las que necesito hacer postbacks con ánimo de mostrar nuevos controles u ocultar otros, pues estos comportamientos rigen el workflow de mi aplicación.

    Bueno, el hecho de que en MVC no exista el mantenimiento de estado automático y los eventos no significa que no puedas conseguir lo mismo… 

    En escenarios simples que atañen únicamente a la presentación, pueden (incluso diría "deben”) solucionarse en cliente. Por ejemplo, si tenemos en un formulario un checkbox de cuyo estado depende la visualización de una sección del mismo (“quiero pagar por banco” –> datos bancarios), es algo que con un poco de scripting puede solucionarse sin tener que forzar un envío al servidor.

    Si es algo más profundo y el escenario requiere envío de información al servidor, es igualmente sencillo. Sólo hay que recordar que un postback básicamente no es más que un envío al servidor del formulario completo y una devolución del mismo manteniendo los valores de los campos. Y por supuesto esto puedes hacerlo muy fácilmente con el framework MVC.

    Eso sí, en ASP.NET MVC se promueve la separación de funcionalidades como medio para facilitar el mantenimiento y testeo de componentes. Es decir, se intenta evitar la creación de elementos mastodónticos, con múltiples funciones y responsabilidades, tan habituales de los webforms.

    Off-topic: aprovecho para comentar que, emho, los postbacks para recargar el formulario son un mecanismo para el programador y no para el usuario. Es decir, nos facilitan la vida enormemente a los desarrolladores, pero desde el punto de vista de la usabilidad son una auténtica aberración: rompen la interacción y despistan al usuario. Si has utilizado un formulario pesado con varios postbacks en una red no demasiado rápida seguro que sabes a lo que me refiero. Aunque a veces no hay más remedio, intento evitarlos al máximo y siempre que puedo los sustituyo por código en script (usando javascript puro y duro, MS Ajax, jQuery o lo que sea), ya sea en MVC o en Webforms.

    > ¿Realmente os ha alegrado la vida MVC?
    Hombre, para alegrarte la vida hay muchas cosas mejores que MVC, te lo aseguro ;-)

    Bueno, aunque la frase está algo manida, es cierto que MVC ha traído un poco de aire fresco al desarrollo web para ASP.NET. A los que nos gusta trabajar pegados al protocolo y controlando lo que ocurre, nos ha devuelto la capacidad de hacerlo, y la sensación de tener de nuevo las riendas bien sujetas; para los fans de las pruebas, aporta mucha facilidad y flexibilidad para hacerlo; para los defensores de los estándares, la posibilidad de generar nuestro propio código, sin aditivos ni colorantes; para los seguidores de las aplicaciones al estilo 2.0, una vía sencilla para implementar Ajax y scripting por doquier… en fin, casi a todo el mundo le aporta algo ;-)

    > ¿Escogeríais MVC en vuestro próximo proyecto empresarial?
    Depende. En mi opinión no se puede generalizar, hay muchos factores a tener en cuenta ante una decisión así. Para no repetirme, en http://www.variablenotfound.com/2010/05/aspnet-mvc-2-quince-cuestiones-que.html#p7 he recogido mis reflexiones al respecto.

    De todas formas, hace tiempo comentaban los propios creadores del framework, y lo que he observado hasta el momento así lo demuestra, que “ASP.NET MVC no era para todos, ni para todo”.

    > Pregunta mas extrema: ¿Es de locos hacer una web pública en WebForms?
    No. Durante muchos años lo hemos hecho y seguro que seguiremos haciéndolo. Simplemente, los desarrolladores ASP.NET tenemos una nueva y magnífica alternativa para crear sistemas para la web.

    >Gracias de antemano,  espero que me echeis un cable para seguir por el camino de MVC o de lo contrario aconsejadme quedarme en el mundo poco purista, pero eficiente, de WebForms.

    Desde mi punto de vista, ASP.NET MVC es algo que vale la pena estudiar para, llegado el momento, decidir con conocimiento de causa qué tecnología conviene aplicar en cada caso. Si no lo conoces nunca sabrás si te pierdes algo ;-)

    Suerte :-)


    José M. Aguilar
    Variable not found
    • Marcado como respuesta César. _ lunes, 31 de mayo de 2010 18:10
    lunes, 31 de mayo de 2010 15:58
  • José, asombrado me tienes. Un 10.

    De tu aporte explicativo y moral saco buenas conclusiones para encarar con ganas MVC (y por lo que veo JQuery en abundancia).

    Por curiosidad, ¿Cómo harías un maestro detalle en la misma página? Por ejemplo, a la izquierda un listado con paginación y a la derecha el detalle. ¿Mediante QueryString refrescando toda la página, verdad?

     

    lunes, 31 de mayo de 2010 18:10
  • Hola, César.

    Me alegro de que hayas optado por introducirte en esta tecnología. Seguro que le sacas provecho. :-)

    Respecto a tu pregunta, el maestro-detalle en una página puedes conseguirlo de muchas formas: desde utilizar recargas de página completas hasta una más espectacular, montando un grid con jqGrid y utilizando Ajax para recargar el detalle en cada selección de fila (mira en este enlace, la demo Advanced>Master detail). De todas formas, como el tema es algo extenso, mejor prepararé un post sobre este tema, que creo que puede interesar a más desarrolladores, ¿te parece?

    Saludos.


    José M. Aguilar
    Variable not found
    lunes, 31 de mayo de 2010 19:08
  • Estoy tomando como referencia este ejemplo http://mvcmusicstore.codeplex.com Si bien, no tiene tests y esos atributos para la validación me parecen algo raros (ya veremos el soporte multi-idioma).  Espero que sea un buen ejemplo pues no he encontrado nada mejor.

    En cuanto al grid que comentas, mi listado es excesivamente custom como para implementarlo.

    Mil gracias Jose M.

    martes, 01 de junio de 2010 11:02
  • hola ,

    te recomiendo que entre a esta pagina tambien te puede servir de mucho http://www.asp.net/mvc

     

    un saludo..

     

    enmanuel grullard

    republica dominicana

     

    miércoles, 18 de agosto de 2010 1:15