Have something to say?
Join LinkedIn for free to participate in the conversation. When you join, you can comment and post your own discussions.
Primer debate para iniciar AUGES :: ¿Es realmente MVC una moda para el desarrollo de aplicaciones Web o es realmente por donde debemos ir con la mayoría de los proyectos Web?.
Todos hemos oído hablar de desarrollo de aplicaciones Web con ASP.NET con WebForms, ahora está dando duro "algo" denominado MVC, también hay muchas siglas por ahí desperdigadas como DDD, MVP, etc.
Desde el punto de vista de desarrollo Web con ASP.NET, ya sea con formularios Web tradicionales o con aplicaciones Web Silverlight, ¿veis realmente a MVC o a otro patrón como el que debemos tener en consideración para la mayoría de los proyectos?, ¿o depende realmente del tipo de proyecto?.
¿Qué sugerencias marcáis para desarrollar proyectos Web con uno u otro patrón o como identificar dónde encaja más uno u otro?.
En definitiva, si esto obecede a una moda o no, y en el caso de no ser así, cómo saber qué mecanismo de programación, patrón, etc., deberíamos utilizar para encajarlo adecuadamente a cada desarrollo Web sabiendo como es obvio, que cada desarrollo es único y diferente. :)
Have something to say?
Join LinkedIn for free to participate in the conversation. When you join, you can comment and post your own discussions.
Diego N. likes this
You, Diego N. like this
37 comments • Jump to most recent comments
Luis
Luis R. • A ver, yo soy de los que piensa que al Cesar lo que es del Cesar, es decir ASP.NET WebForms está más orientado a RAD, no quiero decir con ello que no se puedan hacer grandes cosas y además bien hechas porque se pueden hacer, de hecho en mi empresa desarrollamos muchos con WebForms porque trabajamos sobre SharePoint y no dejamos de usar MVP, testing y para nada usamos el diseñador de Visual Studio... pero si es verdad que ASP.NET MVC es más poderoso y flexible (Testing, Descoplamiento, ligero, control del html, seo...), pero requiere un conocimiento más produndo que WebForms (sobre todo por la perdida de estado), y estas cosas también hay que tenerlas en cuenta a la hora de embarcarte en un proyecto porque dependerá del conomcimiento técnico de los programadores que dispones en tu equipo, porque a lo mejor MVC les rompes.
Un saludo
Pablo
Pablo N. • Yo usaría MVC para todo. Es el camino a seguir, sobre todo si estás empezando no necesitarás nunca WebForms.
Tener proyectos existentes, conocimientos y años de experiencia en WebForms pueden hacerlo más recomendable, también tener controles de servidor, pero desde mi punto de vista sólo eso. Para todo lo demás, MVC.
Ramon
Ramon O. • Yo todavía no tengo una opinión "formada" en MVC. Precisamente he querido hacer un curso para poder "aplicarlo" correctamente en el futuro y así formarme una opinión. En general hay que adquirir experiencia y "equivocarse" para saber si merece la pena o no.
Tiene cosas "agradables" para ciertos tipos de Webs (como las rutas o "paths") que hace que desde el exterior sea más "bonito".
Además usa jQuery por defecto, etc...
Pero eso es algo que TAMBIEN se podría hacer con WebForms. Y que si webforms no lo tiene por defecto es porque es más antiguo. Nada impediria mapear rutas con webforms ni usar controles ajax/jquery en programación tradicional.
Julio
Julio A. • Yo, como muchos de vosotros he vivido todo el proceso de evolución desde el ASP "clásico", pasando por ASP.Net WebForms, hasta llegar a ASP.NET MVC.
En mi opinión, la decisión es clara; sino no tienes la necesidad de usar controles de servidor, yo siempre optaria por desarrollar mediante ASP.NET MVC (con Json, jQuery, etc...).
La curva de aprendizaje es moderada, pero una vez superada, no creo que quieras volver a WebForms.
Un saludo.
José María
José María A. • ¡Buenas!
Desde hace ya tiempo utilizo ASP.NET MVC para todo: aplicaciones de gestión, webs, o lo que sea, y me siento realmente cómodo así.
De hecho, a estas alturas no hay nada de Webforms que eche en falta en MVC. Al principio notas la ausencia de mantenimiento de estado, o algunos controles de servidor, pero con un poco de práctica lo superas pronto. También empiezas desarrollando un poco más lento, como siempre que usas una tecnología distinta a la habitual, pero cuando le pillas el truco vas a toda pastilla.
De hecho, aun sabiendo que la última versión de Webforms ya incorpora algunas de las ventajas clásicas de ASP.NET MVC como las friendly urls o el mayor control sobre el marcado, sigo prefiriendo la arquitectura propuesta por MVC y la potencia del framework, y por supuesto pienso seguir utilizándola y recomendándola para la mayoría de los casos.
Aún así, con relativa frecuencia recibo mails pidiendo consejo sobre si dar o no el salto a MVC con un nuevo proyecto, y siempre respondo lo mismo: no hay que dejar que el entusiasmo vaya por delante del sentido común. Para embarcarse en MVC es necesario saber más de protocolos y lenguajes de la web, y acostumbrarse a una nueva forma de trabajar, y esto requiere su tiempo.
Respecto a lo que comenta Julio, es totalmente cierto: no he visto/escuchado/leído a nadie que conociendo ASP.NET MVC haya optado por abandonarlo y volver a Webforms. Por algo será. :-)
Saludos!
PD: Eh, pero que no soy imparcial, no me echéis demasiada cuenta ;-P
Jorge
Jorge S. • Muchísimas gracias a todos por participar y dar vuestra opinión.
Entonces... ¿podemos afirmar por lo que decís que el desarrollo de ASP.NET WebForms está muerto?. ;)
Pablo
Pablo N. • Totalmente de acuerdo con José María, que de esto sabe mucho más que yo. Pero por complementar, añadiría que para quien empieza la opción es MVC sin duda.
Jorge, no creo que WebForms esté muerto, pero sí cerca de la 3ª edad.
Luis
Luis R. • Yo creo que muerto no está, sobre todo porque está SharePoint y cada vez tiene más adeptos, ya veréis con Office 365, ahora, si en nuevas versiones de SharePoint les da por migrarlo a MVC entonces no se yo...
Un saludo
Jorge
Jorge S. • Perdonadme entonces que me haga defensor del diablo, pero ¿no es una incongruencia entonces afirmar que debemos iniciar todos los desarrollos Web en MVC pero decir sin embargo que debemos seguir utilizando WebForms para ciertos proyectos?.
Dicho de otro modo, ¿existe la posibilidad de desarrollar proyectos con MVC que por ejemplo sean consumidos por SharePoint (no nube) o en nube (Office 365)?.
Me está encantando el debate porque creo que nos está haciendo pensar y eso es lo interesante e importante. :)
Jesus
Jesus J. • Buenas!
No tengo mucho más que aportar a lo que habéis dicho por aquí ya, yo haría cualquier desarrollo web MVC claramente, ya sea el desarrollo de sites de contenido o aplicaciones con funcionalidad más compleja para un entorno corporativo.
Yo viví el final de ASP clásico y el grueso de mi experiencía profesional se basa en desarrollo con ASP.NET Webforms.Debido a ello creo que comprender la esencia de como funciona la Web, es decir el protocolo HTTP de verdad, ha sido mucho más lento.
A menudo me encuentro gente con menos trayectoria y que solo ha vivido ASP.NET Webforms y hacerles entender como funciona MVC realmente les cuesta. "¿Donde están mis controles? ¿Y el Page_Load? ¿Pero como sé si la página tiene el IsPostBack a true o no?".
Si me paro a pensar es un trabajo bestial el que el equipo de MS hizo cuando consiguió replicar el funcionamiento tradicional de las aplicaciones de escritorio en un entnorno Web, pero la Web no es así!!
La Web se basa en peticiones y respuestas y no en persistir datos en la misma pagina, tener ViewState o un ciclo complicado de eventos, simple y plano, yo te pido, tu me respondes.
Al margen de esto (que todos sabemos) también tengo que decir (cuña publicitaria) que la Web es más que la parte de servidor, el lado del cliente hoy día sabemos que es super importante y usar MVC implica tener las ideas muy claras en cuanto al desarrollo con Javascript.
jQuery facilita mucho las cosas, pero más allá de la librería en sí,la organización del código de cliente, el rendimiento o las pruebas unitarias son cosas que deberiamos tener presentes y tristemente para la mayoría de la gente JavaScript es un engorro y un calvario.
Saludos!!
Daniel
Daniel D. • Muy buenas!
Ya me extrañaba a mi que no comentara nada Jesus sobre MVC :-)
A ver, la verdad es que comparto su opinión, pero por darle otro punto de vista yo añadiría el conocimiento del equipo como un factor MUY importante a la hora de elegir MVC o WebForms
Vale, si, parece algo de cajón, pero es que elegir una técnología o un patron o lo que sea no implica que las cosas vayan a salir bien. Seguro que todos habeis visto alguna web decente hecha con Web Forms, alguna con MVC, y muchas (demasiadas) que independientemente del modelo elegido son verdaderos infiernos... y sobre todo a la hora de mantenerlos, cosa que a día de hoy es algo inevitable.
Personalmente a día de hoy, si hiciera algo solo, lo haría con MVC, pero si estoy en un equipo me lo pensaría bastante en función del conocimiento de cada uno... que todavía hay mucha gente que de web (html, http, javascript...) sabe más bien lo justo :-)
Salu2
Eduard
Eduard T. • Bufff... Lo malo de llegar tan tarde a un debate es que ya no quedan apenas ideas nuevas que aportar...
La clave sobre si usar MVC o Webforms en un proyecto web, para mi está en los conocimientos que tenga el equipo (como han mencionado entre otros Daniel y José M). A nivel técnico, en mi opinión, no hay razón alguna para usar webforms en lugar de MVC. Aunque al principio MVC parece más lento y menos productivo que webforms, una vez el equipo alcanza los conocimientos necesarios la productividad se equipara con la de webforms.
Y además al ser el patrón MVC muy usado en cualquier tecnología, te das cuenta de lo fácil que te resulta coger proyectos en otras tecnologías, que también usen MVC (leáse Codeigniter en PHP, RoR, Struts,...).
Saludos!
David
David M. • Yo no creo que WebForms esté muerto para nada. Ni tampoco creo que todos tengamos que seguir en una dirección o en otra. Justamente eso era el argumento que se ha usado siempre en contra de WebForms, que te 'obligaba' a seguir en una única dirección.
MVC evidentemente es más novedoso y, como tal, tiene elementos que lo hacen muy atractivo, pero muchos de esos elementos se los curraba la gente en el pasado por su cuenta. ¿Cuantos de vosotros no os currásteis en su día un traductor de urls para temas de SEO en WebForms?
Personalmente, si yo comenzase un nuevo proyecto web ahora mismo, optaría por MVC3 porque sería una manera de empaparme de él y descubrir todas sus virtudes, pero como todo tiene que verse como una opción más y no como el camino que todos tenemos que andar.
Alejo
Alejo A. • Todo está dicho, llevo programando desde antes de asp y solo puedo decir que creo que el sistema MVC es, para mi, el camino a seguir, no lo considero novedoso ya que sin tener ese nombre muchos ya utilizabamos MVC eso nos ayuda a estructurar la información y trabajar de una manera coherente.
Jorge
Jorge S. • Muchas gracias a todos por vuestros comentarios.
Por cierto... sólo a modo de aclaración.
El patrón MVC no es viejo, es viejísimo. ;)
Sus inicios vienen de los primeros pasos de la orientación a objetos, es decir, viene de muy lejos, concretamente de SmallTalk (¡que recuerdos!), así que la primera vez que se habla de MVC es por el año 1979. Otra cosa diferente es que algunos de nosotros hayamos aplicado algo parecido a MVC en alguna ocasión, y obviamente muy diferente es la aplicación de este patrón a ASP.NET de forma pura y directa con las plantillas de Visual Studio que aparecieron en el año 2007.
Un saludo. :)
Lluis
Lluis F. • Joer... llego tarde (como siempre) :-P
A ver, yo me he tenido que pelear con ASP, ASP.NET tradicional y con MVC, y en mi opinión -y no me considero un experto como Edu o José- Webforms es totalmente antinatural.
No me malinterpretéis, pero la web es la web, y tanto la arquitectura subyacente como los protocolos no se parecen en nada a la programación tradicional de un rich client.
Cualquier intento de intentar hacer una aplicación web como si fuera una aplicación cliente es y será un truño. Hay que reconocer el inmenso trabajo que han hecho los chicos de MS al respecto, ocultando casi toda la complejidad, pero en mi opinión eso genera un engendro difícil de controlar.
Eso ha provocado un montón de sitios hechos con ASP.NET que son muy cucos, pero que cuando empiezan a tener una gran carga de usuarios se arrastran como un caracol. Ya se que se puede tunear, preocuparte por usar el viewstate y la sesión como es debido, usar cachés, etc. Pero cuántos desarrolladores conocéis que se preocupen de esto una vez puesto en producción?
Que MVC es más complejo? Tal vez. Pero cuando superas la curva de aprendizaje todo te parece más natural.
Que ASP.NET no está muerto gracias a SharePoint? Joer, pues por mi casi mejor que lo maten (es broma). Es verdad que es un gran producto, pero las experiéncias que he tenido con él no me han dejado demasiado buen sabor de boca.
Lo único que para mi tiene ASP.NET sobre MVC es que a lo largo de los años se han creado un montón de componentes de terceros, pero hoy en día eso está cambiando y los principales fabricantes están sacando cosas muy chulas para MVC.
Tiempo al tiempo :-)
Carlos
Carlos C. • Pues yo no he trabajado con MVC para .NET, hace unos 4 años trabajaba solo con webforms, cambie de empleo y empece a trabajar con PHP donde adoptamos el framework de Zend y el patron MVC y la verdad me parece excelente, las cosas se hacen mas organizadas, mejor control y mucho se pasa al cliente, lo cual me parece mejor en terminos de rendimiento y aun de presentacion de la informacion al cliente. Tambien como ha dicho Luis o Jesus, me parece que webforms no trabaja naturalmente con aplicaciones web como se manejan en otros lenguajes como ruby, php o perl, como mencione al principio no conozco aun MVC en .NET pero ya lo voy a hacer, imagino que tendre la misma grata experiencia que con PHP y MVC.
David Jesus
David Jesus O. • Yo creo que lo importante de usar algun framework, tecnologia o patron es realmente conocerlo, saber como funciona y poder sacarle el provecho necesario para ser productivos. Muchos adoptan un framework por moda o porque lo escuchan en una charla pero ni saben como esta hecho ni como funciona, yo he estado utilizando ASP.Net MVC desde las betas de la version 1, y la forma que conseguimos de integrarlo con el esquema de aplicacion que estabamos desarrollando fue basado en la simplicidad, nuestra capa V es practicamente inexistente ya que toda la UI esta hecha en EXTJS, los Controllers creo que uno o dos retornaran un ActionResult, ya que casi todos retornan JSONResult y asi integramos tecnologia EXTJS con la agilidad que nos permitio el MVC de ASP.Net. Creo que mientras mas simples, podremos corregir y adaptar mas rapido la aplicacion y por ende seremos mucho mas productivos, esa deberia ser la idea al adoptar algun framework.