ASP.NET MVC como ASP Tradicional?

Cuantos han programado en ASP Tradicional? Es decir, ASP 2 o ASP 3
La verdad es que yo tuve la suerte de vivir la transición, he programado ASP 2 en varias aplicaciones comerciales (recuerdo que llegamos a lanzar un CMS) y pasar al concepto de ASP.NET Web Forms, pues las cosas se hicieron menos complicadas, cierto?

Yo creo que ASP.NET como tal, si no se hace bajo un orden determinado, pues bienvenido el spaggetti! (o no?)
Con ASP.NET MVC las cosas cambian ya que se debe respetar un orden determinado (o no?)

El problema aqui, es que si bien cierto se gana bastante con la separación de responsabilidades (vistas, modelos y controladores), muchas de las personas que se sintieron “aliviadas” con la facilidad de trabajo de los web forms, pues… la complejidad del MVC genera que sientan el retorno del modelo de trabajo ASP, es decir:
– Programación sobre el ASPX, y el temor a las <% %>
– Errores en tiempo de ejecución por omision de “;, ), etc” que a pesar de que la solución, proyecto o página compilen, en tiempo real, se presentan problemas evitables.
– Necesidad por conocer de manera intermedia/avanzada de tecnologias como JavaScript, JQuery, JSON, Jetc :D 

Y demas cosas que muchos ya tenian como olvidadas o “ya saldrá un control que lo resuelva”

Personalmente creo que MVC es un buen framework, pero que trae consigo un modelo de trabajo nos recuerda al buen ASP, que tuvo que ser desplazado por herramientas y modelos que te aseguraban la productividad y cosas como esas.
A pesar de ello, este nuevo framework me atrae y bastante!

Y ya a manera de conversacion, les digo por favor, no me digan que ya depende de uno que forma de trabajo usar. O “que la moto y el auto” (una referencia a la comparativa MVC o no MVC), en palabras simples, que opinan ustedes?

Saludos
@jersson

7 comentarios sobre “ASP.NET MVC como ASP Tradicional?”

  1. El código sphaghetti no es el tag soup. MVC impone una separacion de responsabilidades y consecuentemente, los tags en las vistas están para representar información. EL código spaghetti como dices es cuando se mezcalaban varias responsabilidades.

    Respecto a que se debe conocer tecnologias web, obviamente se trata de desarrollo web y no es descabellado que se deba tener conocimientos de HTTP, HTML, Javascript, todas esas cosas que WebForms intentaba abstraer.

    MVC da lugar a buenas prácticas, que luego el desarrollador lo haga mal es otra cosa.

  2. Justamente creo que ese era el problema de Webforms, que pretendían que se hiciese programación web sin conocer cómo funciona el entorno web. No se puede no conocer HTML, ni Javascript/AJAX/Framework al gusto, ni mucho menos cómo funciona el HTTP.

    Eso sí, se pueden hacer completos desastres tanto en ASP.NET como en MVC si no se va con cuidado, al igual que se podían hacer cosas muy organizadas en ASP aunque el entorno no te pusiera demasiadas facilidades.

  3. Hola Hadi,
    en realidad lo que temo pueda suceder, es eso, que se genere el spaghetti. Esto debido al mal entendimiento del framework, o de la combinacion que tengan con JavaScript u otros.
    De por si el framework me parece excelente, pero como evitas eso ultimo que mencionas «que luego el desarrollador lo haga mal es otra cosa»

    Hola Marc,
    Es cierto, el problema de los web forms es la facilidad que te daba para crear una aplicación (increible decirlo, no?)

    ASP.NET MVC resuelve muchas de estas cosas ya que es un framework -hasta cierto punto- completo que se monta sobre .net, esto de por si ya genera complicaciones por todas las cosas que deberias conocer para aprovechar las bondades del mismo.

    El problema es ese, que MS deberia haber lanzado un MVC con la facilidad de desarrollo de aplicaciones, aqui un pequeño ejemplo:
    – Generar rapidamente las vistas y controladores desde el modelo,
    – Generar los casos de prueba
    – De estos dos, un wizard que permita una rapida configuracion/generación

    Herramientas hay, el mismo T4 deberia aprovecharse desde la caja. Personalmente tengo ya una idea de como acelerar el desarrollo de MVC, pero creo que es obvio el comentario.

    Para terminar, lo que me preocupa en realidad es que el framework como tal, se vea incompleto, mas aun si tenemos un entorno como el VS, que deberia tener al menos un roadmap de mayor integración con MVC

    Saludos.

  4. en mi opinion asp.net logro su cometido, puso un nivel de abstraccion que hasta antes no se habia popularizado de tal manera (ya habia tecnologias similares) y se logro realmente RAD para la web, ademas de eso si uno se queria meter a los fierros igual se podia lograr, creo que la gente generalmente malinterpreta la abstraccion de asp.net y se encierran en que las cosas solo se pueden hacer de una manera cuando la limitante es solo la que ellos mismos se imponen, ciertamente que no hay mucho material sobre alternativas; lo cierto es que asp.net cumple un papel muy importante para el desarrollo rapido de aplicaciones, pero mucha gente vee la arquitectura como una limitante para desarrollar sistemas complejos; afortunadamente asp.net mvc ha tenido buena aceptacion para solucionar esos problemas. Creo que necesito escribir un post al respecto con mi opinion sobre este tema, no digo que asp.net mvc sea malo, pero tampoco asp.net es malo, solo que hay que aprovechar lo mejor de cada herramienta

  5. MMMmmm…
    Para mi webforms tiene dos problemas fundamentales.
    El primero es el que ha dicho Marc: intenta abstraer demasiado. Un nivel de abstracción es siempre bueno, pero webforms va demasiado allá. No solo porque intenta abstraernos de html y javascript, sinó porque también lo intenta hacer de http: el modelo de aplicación «conectada» winforms se exporta muy mal al mundo web.
    El segundo es que en general el modelo «formulario» no es el mejor modelo para desarrollar aplicaciones concretas: está demostrado que un menor acople y patrones como «separated presentation» funcionan mucho mejor para crear aplicaciones más mantenibles. En Winforms tenemos a CAB, en WPF a PRISM y ahora para ASP.NET tenemos al framework de MVC.
    Uno debe hacer un cambio de mentalidad cuando pasa de webforms a MVC… exactamente lo mismo que cuando uno pasa de hacer la típica aplicación winforms a usar CAB… 🙂

    Confundir el uso de < % %> con el spaghetti code probablemente sea la herencia que nos ha dejado el ASP clásico… pero en una vista todas las etiquetas < % %> deben referirse únicamente a temas de presentación. Esto no es ni mucho menos el código spaghetti que teníamos en ASP (otra cosa es que sea más complejo de leer, aunque en este punto motores alternativos de vistas pueden ayudar).

    … además de que tendemos a hacer muchas cosas con < % %> olvidando el tremebundo poder de jquery… 😉

    Si el problema es evitar «que el desarrollador haga mal las cosas», me temo que estamos ante un callejón sin salida…

    Saludos!

    pd: Esto no quita jersson que algunas de las mejoras que propones no sean interesantes… pero yo el «RAD clásico» con MVC no lo veo.

  6. Eber, muy de acuerdo al respecto. El problema ya radica en que contexto usar que herramienta, lenguaje, framework. O la combinacion de las mismas, sin caer en aspectos muy «spaghetti» o «mazamorra» como dice un amigo mio.

    Eduard, en realidad aqui complementaré lo que mencionó Eber, la idea es tomar lo mejor de cada lado. pero tampoco no deberiamos tener un Visual Studio tipo notepad, es decir, yo creo que con siguientes liberaciones del VS10 este IDE deberia tener mayor soporte a ASP MVC, sino, la potencia de VS10 se veria disminuida.
    Creo yo, VS10 tiene un tope que superar, ya que segun recuerdo VS2008 ha sido catalogada como una de las mejores herramientas de trabajo. Asi que, es por ese lado que espero como MINIMO, genere toda la estructura de manera «nativa», es decir, sin necesidad de implementar nosotros mismo la generación del código respectivo (se viene un post al respecto!)

    Sin mas me despido, esperando mas comentarios, pues este tema si que es interesante.

    @jersson

  7. Yo concuerdo totalmente con Hadi, Marc y Eduard, hace dias «discutia» esto con un MVP, pero parece que no se llega a un acuerdo y mas que una cuestion de gustos, en realidad WebForms tiene un problema que hay que reconocer que es el EXCESO de abstraccion y querer «simular» sí «simular» el Desktop en la Web

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *