ASP.NET MVC me recuerda al viejo clásico ASP spaghetti code

Si no le gusta el motor de vista predeterminado, puede usar otro.

Según El blog de Scott Guthrie :

Una de las cosas que el equipo ha hecho con ASP.NET MVC es asegurarse de que puede usar cualquier tipo de "motor de visualización" que desee con él. Esto proporciona mucha flexibilidad para personalizar el motor de renderizado como quieras.

Vamos a investigar algunos motores de vista más declarativos en el futuro, aunque nada específicamente planeado solo aun.

Ejemplos de Vista alternativos motores son NHaml discutido aquí, Chispa discutido aquí y NVelocity discutido aquí.

Finlay Microsoft está corrigiendo su error con ASP-Classic para ASP.NET paso. el 70% de los antiguos programadores asp fueron a PHP porque ASP.NET era demasiado complejo.

Es difícil que todo se pueda resolver con ASP.NET menús de drogas y drop. Y al final todo está dentro de forma etiqueta! Estamos construyendo grandes "formularios web" no sitios web. Basta con mirar el HTML de cualquier ASP.NET sitio. Absolutamente horrible!

ASP.NET MVC es la nueva ESPERANZA para un código HTML más limpio y más organizado y potente lógica de negocios.

MVC vs. genérico ASP.NET como la diferencia entre transmisiones automáticas y manuales. Utilice un manual si desea determinar qué marcha utilizar para qué fines, cuándo cambiar y optimizar la eficiencia. Utilice el automático si desea algo que solo funciona, pero puede no estar muy bien optimizado, o flexible, o fácil de depurar (que no tendrá que hacer tan a menudo.)

Classic ASP era una transmisión manual con solo segunda marcha.

La diferencia es que en MVC lo único que hace la vista es renderizar la pantalla. Toda la lógica de negocio, el manejo de E/S y el código relacionado con el modelo se encuentran en las clases controllers y model. La cantidad de código que se encuentra en la vista es relativamente pequeña y compacta, y puede abstraerla en controles de usuario (vistas parciales) si se usa comúnmente.

Personalmente, me gusta el control adicional que tengo sobre la vista. La mayor parte de mi tiempo con webforms parecía haber pasado tratando de trabajar alrededor de las suposiciones predeterminadas que se hicieron (y el nombre mangling introducido por las páginas maestras/secundarias) que hicieron difícil hacer mucho de cualquier cosa del lado del cliente.

EDIT : Olvidé mencionar la capacidad de crear métodos de extensión HtmlHelper que también te permite mover muchas cosas al backend. En general, entre los controladores, modelos y métodos de extensión se suma mucho más código que se puede probar fácilmente en MVC que en ASP clásico o ASP.NET Formularios WEB.

Creo que el problema con el ASP.NET view engine es que no hay restricciones sobre lo que puede hacer, ya que es solo un lenguaje.NET incrustado en XHTML.

Por el contrario, echa un vistazo al motor de plantillas de Django. En el framework Django, los controladores y modelos se escriben usando el lenguaje Python completo, pero el motor de plantillas de vista define un lenguaje restringido que solo proporciona construcciones de programación básicas (condicional, bucles, etc.). Este el lenguaje restringido se asemeja a Python, pero en realidad no es Python, por lo que no puede invocar código arbitrario como bibliotecas externas. Solo puede acceder a los datos del modelo que se pasan a la vista.

Cualquier motor de vista que incorpore un lenguaje de propósito general va a tener el problema de que la gente abusa de él y hace cosas que no deberían en la vista. Entonces, con esos motores, realmente necesita tener la diligencia debida para evitar hacer cosas que no sean acceder a los datos del modelo.

Después de programar MVC por un tiempo ahora, voy a volver a ASP.NET.

MVC es de hecho un buen paso adelante de ASP clásico o PHP, pero es un gran paso atrás en comparación con ASP.NET.

Muchas cosas que se pueden programar con unos pocos pasos en ASP.NET necesito mucho más trabajo en MVC. Por lo que es más difícil cumplir con los plazos.

La tecnología tiene sus méritos, pero aún no está madura.

Tal vez en la versión 3.0 ...

Esto fue mencionado en PDC, mencionaron que era un poco demasiado "clásico asp" como con todo el

La dirección completa para ellos es obtener una versión estable, luego hacer que sea más fácil trabajar con ella.

PDC Video: http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/PC21.wmv

Se trata de separar las preocupaciones. En el ASP clásico, era una mezcla de lógica de negocios y lógica de presentación, con inclusión desagradable lanzado en las bibliotecas.

La sintaxis es similar en este punto, pero el propósito no lo es. En la vista, solo debería estar haciendo la lógica de presentación. Usted todavía puede poner la lógica de negocios allí, nada lo detiene (por desgracia). Depende del desarrollador, que sigue siendo mi mayor preocupación.

Echa un vistazo al motor de vista StringTemplate, se ve bien y limpio.

Siempre me sorprende la falta de comprensión del diseño de n-capa/nivel demostrado por algunos de los partidarios más fuertes de asp.net mvc. SOC siempre ha sido posible en los formularios web. Los patrones de interfaz de usuario como MVP siempre han sido alcanzables en los formularios web. No es la falla de las plataformas que tantos desarrolladores no saben diseñar.

Personalmente, prefiero el patrón MVP sobre el MVC.

Porque a la gente detrás de MVC realmente le gustaron las páginas ASP/JSP y quieren implementarlo de nuevo. Parecen odiar:

• Estado de vista
• Existente ASP.Net Controles
• Limpiar Html
• Controles de Usuario existentes
• Postbacks

Parecen amar:

• Reinventar la rueda
• Url REST-ful

MVC es esencialmente una forma de forzar una separación de código de la presentación. Si un desarrollador realmente se preocupara lo suficiente, esto podría ser fácilmente achieved con normal Asp.Net.De todos modos, es posible hacer punk con todo el sistema de "separación", así que realmente no veo el punto.

Dicho esto, hay algo de mérito en ello.. pero no lo suficiente para superar los problemas. MVC versión 3 Estoy seguro de que será impresionante.

Y antes de que alguien me marque -1, vea cuántas preguntas MVC he respondido. Sé de lo que estoy hablando.

ACTUALIZACIÓN Si usted está tomando su separación en serio, al mirar es, chaiguy1337 está en una buena cosa. La plantilla de cadena se ve muy bien porque no permite ningún código en su front end! En mi opinión, el ASP.net El equipo MVC dejó caer el balón en MVC.

En el ASP clásico, no tenía opción de mover la lógica de negocio fuera de la capa de interfaz de usuario. En ASP.Net MVC, el código" spaghetti "está aislado de la capa de interfaz de usuario, la Vista; el 90% de su lógica estará en las capas" M "y" C", que son clases regulares de C# que no son spaghetti.

La vista está destinada a ser "tonta". No hay nada crítico desde una perspectiva de lógica de negocios. Está destinado a ser casi desechable.

Puede pintar una habitación desordenadamente sin hacer ningún daño a la estructura. Si decide limpiarlo y volver a pintar, no necesitas llamar al arquitecto. Mismo con la Vista.

Para que conste:

Creo que el problema real con ASP MVC es el controlador, es trivial (en la mayoría de los lenguajes) usar (o emular) algún esquema de plantilla (incluso en ASP classic) y cualquier lenguaje puede hacer modelo (con objetos o no) pero MVC te obliga a separar el controlador de la vista y el modelo, inflando el código en el proceso.

Un sitio web común se basa en la forma completa-post / get y en AJAX, si utiliza ambos entonces se convierte en" C " de MVC en un desorden.

En última instancia, la mayoría de los programadores terminan "haciendo trampa", poniendo la llamada ajax en la capa de VISTA.