cshtml - ASP.NET MVC me recuerda el antiguo código clásico de spaghetti ASP
razor reference (14)
Acabo de revisar algunos tutoriales de MVC luego de revisar este sitio por un tiempo. ¿Soy solo yo, o las páginas de MVC View traen recuerdos HORRIBLES del código de espagueti ASP clásico con todos los saltos dentro y fuera de HTML y ASP.NET con delimitadores amarillos en todas partes que hacen que sea imposible de leer? ¿Qué pasó con la importancia de la separación de código / diseño? Realmente me vendí con la nueva tecnología hasta que los tutoriales llegaron a la sección Ver desarrollo de páginas.
¿O me estoy perdiendo algo? (Y no diga que puede usar la plantilla para ayudar porque simplemente mueve los espaguetis a otra ubicación, la barre debajo de la alfombra, no soluciona el problema)
Mira el motor de vistas StringTemplate , se ve bien y limpio.
Esto fue mencionado en PDC, mencionaron que era un poco demasiado "asp clásico" como con todo el <% =. Pero también mencionaron que agregarán etiquetado y controles ASP.Net estándar.
Toda la dirección para ellos es obtener una versión estable y luego facilitar el trabajo.
Video de PDC: http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/PC21.wmv
MVC vs. ASP.NET genérico como la diferencia entre transmisiones automáticas y manuales. Use un manual si desea determinar qué equipo usar para qué fines, cuándo cambiar y optimizar para obtener más eficiencia. Use la función automática si quiere algo que simplemente funciona, pero que puede no estar muy bien optimizado, o ser flexible, o fácil de depurar (que no necesitará hacer tan a menudo).
Classic ASP era una transmisión manual con solo segunda marcha.
Se trata de separación de preocupaciones. En ASP clásico, era una mezcla de lógica de negocios y lógica de presentación, con desagradable incluye lanzamientos para las bibliotecas.
La sintaxis es similar en este punto, pero el propósito no es. En la vista, solo debería estar haciendo lógica de presentación. Todavía puede poner lógica de negocios ahí, nada lo detiene (desafortunadamente). Depende del desarrollador, que sigue siendo mi mayor preocupación.
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 una gran flexibilidad para personalizar el motor de renderizado como lo desee.
Vamos a investigar motores de vista más declartivos en el futuro, aunque nada específicamente planeado todavía.
Ejemplos de motores de vista alternativos son NHaml discutidos aquí , Spark discutido aquí y NVelocity discutido aquí .
vea la publicación de Jeff ( http://www.codinghorror.com/blog/archives/001155.html ) que hace eco de su pregunta, y la respuesta de Rob Conery ( http://blog.wekeroad.com/blog/asp-net-mvc- avoid-tag-soup / )
En resumen, ASP.NET MVC ofrece a los desarrolladores la opción de fotografiarse en el pie, aunque es ciertamente posible hacerlo de forma limpia. Como tal, es adecuado para desarrolladores que se sienten cómodos con el desarrollo web y que tienen un estilo limpio, pero no es para los desarrolladores que quieren un comportamiento Widgetizado como los winforms sin tener que profundizar demasiado en el marcado.
La diferencia es que en MVC lo único que hace la vista es renderizar la pantalla. Toda la lógica comercial, el manejo de E / S y el código relacionado con el modelo se encuentran en los controladores y clases de modelos. La cantidad de código que se encuentra en la vista es relativamente pequeña y compacta, y puede resumirlo 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 del tiempo que pasé con los formularios web parecía estar dedicado a tratar de evitar las suposiciones predeterminadas que se hacían (y el cambio de nombre introducido por las páginas maestras / secundarias) que hacían que fuera difícil hacer cualquier cosa al lado del cliente.
EDITAR : Me olvidé de mencionar la posibilidad de crear métodos de extensión HtmlHelper que también te permiten mover un montón de cosas al back-end. Con todo, entre los controladores, los modelos y los métodos de extensión se agrega mucho más código que es fácilmente comprobable en MVC que en ASP clásico o ASP.NET WebForms.
Creo que el problema con el motor de vista ASP.NET es que no hay restricciones sobre lo que puede hacer, ya que es solo un lenguaje .NET incrustado en XHTML.
Por el contrario, eche un vistazo al motor de plantillas de Django . En el marco de Django, los controladores y modelos se escriben utilizando 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 lenguaje restringido se asemeja a Python, pero en realidad no es Python, por lo que no puede invocar código arbitrario, como las 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 las personas lo abusen y hagan cosas que no deberían en la vista. Entonces, con esos motores, realmente debe tener la diligencia debida para evitar que haga otras cosas además de acceder a los datos del modelo.
Finlay Microsoft está corrigiendo su error con ASP-Classic a ASP.NET. El 70% de los antiguos programadores de ASP fueron a PHP porque ASP.NET era complejo.
Es difícil que todo se pueda resolver con medicamentos de ASP.NET y menús desplegables. ¡Y al final todo está dentro de la etiqueta de formulario ! Estamos construyendo un gran "formulario web", no sitios web. Solo mire el HTML desde cualquier sitio ASP.NET. ¡Absolutamente horrible!
ASP.NET MVC es la nueva HOPE para un código HTML más organizado y una poderosa lógica comercial.
En el ASP clásico, no tenía la opción de sacar la lógica comercial de la capa de interfaz de usuario. En ASP.Net MVC, el código "spaghetti" está aislado en la capa UI, la Vista; El 90% de tu lógica estará en las capas "M" y "C", que son clases de C # regulares, sin espagueti.
The View está destinado a ser "tonto". Nada crítico allí desde una perspectiva de lógica de negocios. Está destinado a ser casi desechable.
Puedes pintar una habitación desordenadamente sin dañar la estructura. Si decide limpiarlo y volver a pintar, no necesita llamar al arquitecto. Lo mismo con la vista.
Porque a las personas detrás de MVC realmente les gustaban las páginas ASP / JSP y querían implementarlas una y otra vez. Parecen odiar:
- ViewState
- Controles ASP.Net existentes
- Limpiar html
- Controles de usuario existentes
- Postbacks
Parecen amar:
- Reinventando la rueda
- URLs REST-ful
MVC esencialmente es una forma de forzar una separación de código de presentación. Si un desarrollador realmente se preocupa lo suficiente, esto podría ser fácilmente logrado con Asp.Net normal. Es posible punk todo el sistema de "separación" de todos modos, así que realmente no veo el punto.
Dicho esto, hay algunos méritos ... pero no lo suficiente como para superar los problemas. MVC versión 3 Estoy seguro que será increíble.
Y antes de que alguien me marque -1, mira cuántas preguntas de MVC he respondido. Sé de lo que estoy hablando.
ACTUALIZACIÓN Si tomas en serio tu separación, al mirarla, chaiguy1337 está en algo bueno. String Template se ve muy bien porque no permite ningún código en su interfaz. En mi opinión, el equipo ASP.NET MVC dejó caer la pelota en MVC.
Después de programar MVC por un tiempo, vuelvo a ASP.NET.
MVC es un buen paso adelante del clásico ASP 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 necesitan mucho más trabajo en MVC. Haciendo 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 ...
Para el registro :
Creo que el verdadero problema 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 clásico) y cualquier lenguaje puede hacer un modelo (con objetos o no) pero MVC te obliga a separar el controlador de la vista y el modelo, hinchando el código en el proceso.
Un sitio web común se basa en full-form-post / get y en AJAX, si usa ambos, entonces usted convierte "C" de MVC en un desastre.
En última instancia, la mayoría de los programadores terminan "haciendo trampa", poniendo la llamada ajax en la capa VER.
Siempre me sorprende la falta de comprensión del diseño n-layer / tier demostrado por algunos de los más entusiastas partidarios de asp.net mvc. SOC siempre se ha podido lograr en webforms. Los patrones de UI como MVP siempre se han podido lograr en formularios web. No es culpa de las plataformas que muchos desarrolladores no saben cómo diseñar.
Volviendo a la pregunta de spaghetti, tengo que estar de acuerdo. La vista no es "tonta" como debería ser si contiene una lógica condicional o toneladas de fragmentos de código no comprobables.
Personalmente, prefiero el patrón MVP que el MVC.