2008-11-08 15 views

Respuesta

7

No. Personalmente, creo que MVC funciona mucho más como lo hace mi cerebro con una separación bastante clara de lo que va y por qué. Me deshice de un prototipo completo de sitio de comercio con MVC en unas pocas semanas que me hubiera llevado, estoy seguro, al menos el doble de usar formularios web.

+0

"MVC funciona mucho más como lo hace mi cerebro con una separación bastante clara de lo que va y por qué" - En segundo lugar, fragmenté el código mucho más rápido casi inmediatamente después de 'soplar' MVC. – chakrit

+2

@chakrit - Creo que te refieres a 'grokking' - http://en.wikipedia.org/wiki/Grok –

5

En este punto, WebForms es más maduro. Deseo, por ejemplo, que la validación (cliente y servidor) tenga mejor soporte en MVC. Sin embargo, espero que, con el tiempo, esto mejore. Lo mejor de MVC desde mi perspectiva es que MVC hace que mi código sea mucho más comprobable. Estaba dejando mucho código sin probar con WebForms simplemente porque era demasiado difícil probar el código detrás. Ahora puedo escribir pruebas unitarias para toda la lógica de mi controlador.

Aunque eventualmente resulte que MVC es algo más lento (y supongo que no será así), una comprobabilidad mejorada lo haría valer la pena. Eventualmente recuperaré ese tiempo, ya que habrá menos regresando y reparando el código fallado, no probado más tarde.

+0

¡se supone que es más rápido! –

7

Con MVC, nunca pierde el tiempo tratando de averiguar por qué ItemDataBound y ItemCommand no se activan cuando espera.

Si crees que eso te ahorrará tiempo, entonces MVC es probablemente para ti.

+2

Te escucho. WebForms parece rápido cuando puede simplemente colocar una cuadrícula o control de algún tipo en un formulario y conectarlo a un origen de datos. Pero cuando estás depurando eventos y persiguiendo tu cola, pronto se vuelve doloroso. – Craig

3

Me parece MVC un ajuste mucho más natural para el desarrollo web. Como ha señalado el cartel anterior, sin duda ahorrará tiempo al no tener que lidiar con errores extraños generados por la vida de ejecución de la página de formularios web.

Además, la capacidad de escribir pruebas unitarias para su lógica mucho más rápidamente (¡y con mucha menos dependencia de los simulacros!) Es una gran ventaja.

Finalmente, he encontrado que es mucho más fácil escribir scripts de css y de cliente cuando se usa el framework MVC ya que puede especificar sus propios ID en elementos HTML.

-1

Depende de cómo se desarrolle.

Si usted es alguien que arrastra controles a la superficie del diseñador, probablemente sea difícil igualar ese nivel de desarrollo rápido con MVC.

Por otro lado, si pasa la mayor parte de su tiempo en la vista de origen, probablemente encontrará que MVC le permite hacerlo de manera más eficiente.

Trayendo AJAX a la imagen, si eres de los que confía en UpdatePanel, MVC probablemente sería indeciblemente miserable para ti.

(Esto no comienza a abordar la cuestión subjetiva de qué tipo de desarrollo es más "correcta". No creo que ese es el punto de esta pregunta, sin embargo.)

1

creo que finalmente será MVC el claro ganador para Desarrolladores Web. Sin embargo, ASP.Net mantendrá un papel muy importante porque siempre habrá chicos de .NET que se consideren desarrolladores web que en realidad son tipos de Windows Forms. ASP.NET sans MVC te permite juntar cosas rápidamente, pero puedes terminar fácilmente con HTML, CSS y JavaScript horribles, terribles y profanos. MVC abre la puerta a lo maravilloso, pero requiere un enfoque más disciplinado por parte de los desarrolladores.

+1

Debe aclarar que quiere decir formularios web de ASP.NET. MVC también se basa en la pila de ASP.NET –

3

Cuando escucho el término "desarrollo rápido", encuentro que las personas suelen usarlo en el contexto de "qué tan rápido puedo desarrollar una nueva solución". Hay muchos factores que deben considerarse antes de poder construir una respuesta razonable.

  • ¿Qué tan familiar es el desarrollador con el marco?
  • ¿Cuán completo es el diseño?
  • ¿Cuán complejos son los requisitos?
  • ¿Qué tan estable es el marco?

Me puse en contacto por primera vez con ASP.NET MVC poco antes de que se lanzara 1.0. Antes de eso, estaba muy familiarizado y muy cómodo con ASP.NET WebForms, pero todavía estaba frustrado con el proceso de desarrollo en general. Era consciente de los objetivos que rodean la separación de las preocupaciones, y sabía lo suficiente que la separación clara no era posible con WebForms sin nadar contra la corriente creada por el marco.

Desde que trabajé con ASP.NET MVC, me di cuenta rápidamente de que me faltaba el barco en varias cosas. Si bien WebForms le permite construir cosas "más rápido", la implementación de Microsoft básicamente lo toma como rehén en lugar de permitirle digerir estándares establecidos más fácilmente (como JavaScript, CSS y AJAX) en entornos que no involucran a Microsoft. Además, la creación de nuevas herramientas, comportamientos y funcionalidad no debe estar motivada por las ventas y la rentabilidad, sino porque las demandas tecnológicas de la comunidad de desarrolladores lo requieren. He estado trabajando en este proyecto actual de MVC desde abril. Me gusta mucho trabajar con este framework y lo recomendaría mucho a cualquiera que esté interesado en abandonar WebForms. Aprender el marco requiere algo de tiempo, pero una vez que lo entiendes, literalmente te preguntas por qué no pudiste haber hecho las cosas de esta manera desde el principio.

Puede construir aplicaciones más rápido con WebForms, pero, si desea sitios web de aspecto profesional, deberá invertir en bibliotecas de componentes que aún requerirán que aprenda esos estándares establecidos para aprovecharlos adecuadamente. Si mi hijo de 11 años expresara su interés en aprender el desarrollo web mañana, dada la opción de WebForms o MVC, mi elección sería MVC. Dicho esto, aún así lo dirigiría hacia el aprendizaje de JavaScript, jQuery y AJAX antes de que incluso tocara MVC, porque entender esos marcos hace que la comprensión de casi todos los demás sea mucho más fácil.

Personalmente, no soy un defensor del "desarrollo rápido". Pasé mi carrera como desarrollador corporativo y veo el desarrollo interno como una inversión. Preferiría gastar un 20% más de tiempo en diseño y desarrollo en lugar de acortar el proyecto en un 20% solo para cumplir con un plazo poco realista. Cada dólar "ahorrado" durante el desarrollo inicial le costará fácilmente al menos $ 1.50 debido a los costos de mantenimiento, reeducación y cambios arquitectónicos debido a nuevos requisitos. Pero, no todos piensan como yo, así que ... mi respuesta simple sería MVC.

0

Cuando se trata del primer 90% de desarrollo, WebForms es el claro ganador. Es ese último 10% ese es el problema y donde MVC tiene la ventaja.

+2

... donde el último 10% toma el otro 90% de su tiempo. –

9

Cuando se trata de la productividad de ASP.NET MVC vs. ASP.NET Web Forms, considere estos dos desarrolladores.

  1. .NET Genérico desarrollador que tiene una amplia experiencia escribiendo WinForms y WebForms aplicaciones.
  2. Desarrollador genérico de aplicaciones web que puede escribir código C#, pero conoce HTML, CSS y jQuery/MooTools/etc como la palma de su mano.

The Genérico.NET Developer será más eficiente al escribir código en el original ASP.NET Web Forms. Esto se debe a que conocen muy bien los modelos de eventos (ya que se duplican entre WinForms y WebForms) y podrán crear rápidamente un sitio web utilizando este modelo mental.

  • MVC tendría una curva de aprendizaje grande porque es una salida completa de su conocimiento existente de "¿Cómo funciona la web". Estos son los obstáculos que encontrará este desarrollador con MVC:
    • Tener que aprender HTML y CSS hasta el punto en que entienden lo que está sucediendo y cómo las cosas interactúan entre sí.
    • Aprendiendo javascript y cómo devolver la llamada al servidor para ajax.
    • Descubre cómo mantener el estado, descubrir que las cookies no son seguras y que la sesión tiene ciertos "errores".

La aplicación Web Genérico desarrollador será más eficiente en ASP.NET MVC porque el marco refleja la forma en que piensan de aplicaciones web - no hay eventos, sin estado de la aplicación, etc. Ellos Ya sé cómo escribir un buen HTML y darle un estilo con CSS, saben cómo escribir una llamada ajax en el servidor.

  • Web Forms no es un buen modelo para este desarrollador, ya que es un punto de partida de su conocimiento existente de "¿Cómo funciona la web". Estos son los obstáculos que encontrará este desarrollador con los formularios web de ASP.NET:
    • Habrá que invertir tiempo tratando de descubrir cómo funciona el ciclo de vida de la página.
    • ViewState causará muchos problemas, la página se hinchará.
    • Gran parte de la piratería HttpRequest por lo general tendrá que llevarse a cabo para arreglar todo el código incorrecto que sale de ciertos controles de WebForm.
    • Aprender cómo lidiar con las devoluciones de llamada AJAX en lugar de simplemente utilizar su conocimiento existente de cómo llamar a una URL de jQuery.

Mi punto principal es que los desarrolladores de diferentes tendrán diferentes niveles de productividad en base a su experiencia previa con el desarrollo web. Personalmente prefiero ASP.NET MVC, puedo construir algo muy rápido y hacer que salga exactamente lo que pretendo.

Soy el desarrollador # 2, escribí aplicaciones web (la mayoría de ellas pequeñas) en Ruby on Rails, Django, ASP.NET Web Forms y ASP.NET MVC. El conocimiento del desarrollo web entre estos 3 marcos es casi intercambiable (con la excepción de tener que conocer el lenguaje de alojamiento - ruby ​​vs. python vs. C#).

Lo más exasperante encuentro con ASP.NET Web Forms es que se trata de hacer demasiadas cosas para el desarrollador (cosas como el estado de aplicación, eventos web), la salida de código menudo no juega bien con la Web Estándares, Web Forms 2.0 está ligado directamente a XHTML 1.0 Transitional. Cualquier cosa que vaya más allá de un DataGrid rápido y sucio y filas de CRUD en una base de datos por lo general causa más dolor y sufrimiento en comparación con escribirlo en ASP.NET MVC.

-5

WOW. He estado usando controles ASP.NET durante casi 5 años y ahora escucho sobre este nuevo chico en el bloque - MVC

Supongo que MVC fue creado para que los desarrolladores de PHP lo crucen. No puedo ver ninguna otra razón MAYOR para hacerlo. Pero, no conozco MVC así que no me escuches. Solo estoy haciendo una conjetura.

Soy bastante rápido en ASP.NET ASP.NET formularios y enlace de datos. Cuando me apoye MVC volveré y haré un comentario

+0

"Cuando compre MVC volveré y haré un comentario". Pero lo hiciste ... –

+0

Sí, y después de aprender cómo funciona MVC, no estaría en mi mente dejar Winforms para MVC. Los trucos no convencionales que hacemos en webforms no son replicables en MVC sin TONELADAS de código. MVC = toneladas de código – DonP

0

Es muy extraño por qué tanta gente piensa que no es posible en Web Froms para obtener HTML limpio, use jquery (y jquery ajax), escriba css (?) . Que siempre debe arrastrar y soltar los controles desde la barra de herramientas, cuando en realidad puede escribir de la misma manera que lo hace en MVC.

Las páginas web del ciclo de vida, viewstate, databinding, updatepanels también requieren tiempo para aprender si usted quiere escribir un buen código. Parece que la mayoría de la gente no dedica tiempo a esto, por eso dicen que WebForms "no es tan bueno".

Mientras soy un desarrollador maduro de Web Froms, intento aprender MVC (solo por diversión) y es lo suficientemente bueno para escribir sitios web complejos. Pero como veo ahora, el problema principal con MVC es que tienes que escribir un montón de código, ¡¡¡realmente mucho !!!

0

He estado usando ASP.NET desde que se entregó la primera versión beta en la Conferencia de Desarrolladores Profesionales en Orlando en 2000. Así que, obviamente, estoy mucho más cómodo con WebForms, porque eso es lo que comencé. La mayoría de las objeciones a WebForms se pueden superar con mecanismos de desarrollo sensato. Pero, aunque WebForms proporciona una infraestructura para RAD en la web, me gusta MVC también. MVC aún está madurando, y estoy seguro de que será aún mejor. La conclusión es "¿dónde estás?" En la escala de tiempo de aprendizaje de desarrollo, y qué experiencia previa tienes. Tienes que tomar esa determinación por ti mismo. Si eres nuevo, puedes darte el lujo de investigar ambos.

Cuestiones relacionadas