tag route page net mvc data asp all .net asp.net-mvc html-helper

.net - route - html helpers mvc 5



ASP MVC HTML Helpers-¿Bueno o malo? (4)

Creo que un punto importante que los otros no han mencionado es la portabilidad de sus puntos de vista.

Puede mover su HTML, javascript y CSS a una aplicación en otra plataforma inmediatamente. No tienes que convertir todos los HTMLHiders feos ... lo siento, HTMLHelpers ... a HTML real.

Si bien tengo el mayor respeto por el marco .NET que reduce mi tiempo de desarrollo y facilita mi trabajo, creo que las vistas no deben ser propietarias.

De todos modos, puede obtener casi todos los beneficios del marco en el modelo y el controlador. Inyectar dependencias en el marco en su capa de presentación no vale en absoluto la compensación, OMI.

Entiendo la razón para tener los ayudantes de HTML en ASP.NET MVC y extender esto para proporcionar el suyo propio, pero me pregunto si usar los ayudantes de HTML es una buena idea.

Pensé que uno de los beneficios de ASP.NET MVC es el control sobre el HTML. Si empiezas a esconderlo en las funciones auxiliares que generan HTML, ¿no empiezas a perder visibilidad? Supongo que esto no es un problema cuando se generan controles simples como un botón, pero he visto el uso de ayudantes html para crear cuadrículas y resultados HTML más complejos.

Ahora también entiendo que la razón para hacerlo es mantener las cosas en seco, evitando la duplicación. Pero, ¿no existe el peligro de tener algo parecido a un código subyacente aquí? Además, ¿qué pasa si estás trabajando en colaboración con diseñadores? Generalmente el diseñador estaría creando el marcado y aplicando el estilo. Si comienza a inyectar su vista con ayudantes que generan un marcado, ¿esto no dificulta tal colaboración?


Definitivamente no hay nada malo con los ayudantes. Se utilizan para mantener sus puntos de vista limpios y declarativos. Hay un dicho que dice algo como "si hay una declaración" si "en tu opinión, lo estás haciendo mal". Se utilizan en muchos frameworks MVC prominentes como Ruby On Rails y Cake PHP. Echa un vistazo a esta publicación . "Puristas" o no, los ayudantes son una buena cosa y no deben confundirse con malas prácticas o abstracciones con fugas.


El "control sobre el HTML" es el lenguaje de marketing de Microsoft, y es la forma en que están eligiendo la marca de la plataforma. El punto de ASP.net MVC es que es más simple y se adapta mejor a las aplicaciones web que a todo el modelo de formularios web impulsado por eventos con estado, y es algo que prácticamente todos fuera del espacio de Microsoft pasaron hace años. Sin embargo, Microsoft no puede decir eso, porque tienen una gran inversión en formularios web, y es una parte clave de su historia empresarial.

Dicho esto, si tiene lógica empresarial en sus ayudantes, los está utilizando mal. Básicamente, el código de la lógica de presentación está duplicado en varias páginas, y el objetivo es mantener las etiquetas de scriptlet en el marcado lo más simple posible.

Siempre que utilice a los ayudantes de la forma en que deberían usarse, debería ser bastante trivial para los diseñadores aprender a usarlos. Solo recuerde que el objetivo es mantener las cosas simples, si terminan haciendo las cosas más complejas, significa que no se están utilizando correctamente.


Gran comentario, Matt. Todavía queda la pregunta de si en una implementación MVC "pura", los ayudantes de HTML son una buena idea. Creo que esa es la palabra mágica, "puro". Cada vez que me detengo para pensar en la forma "correcta" de hacer las cosas, realmente estoy tratando de ver si un enfoque particular encaja con la visión del purista. Entonces, ¿un purista usaría ayudantes de HTML?

Soy aproximadamente 8/10 purista y no los usaría. He visto que este argumento trasciende las tecnologías y he planteado el problema con MVC en PHP y el marco Zend. Simplemente no se siente bien y para mí, esa es la mejor medida que se puede lograr.