ASP MVC HTML Helpers - ¿Bueno o malo?

Question

Entiendo la razón para tener los ayudantes de HTML en ASP.NET MVC y extendiendo 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 del HTML. Si comienzas a esconderlo en funciones de ayuda 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 helpers html para crear grillas y una salida HTML más compleja.

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

Answer 1

"Control sobre el HTML" es un discurso de marketing de Microsoft, y es la forma en que eligen marcar la plataforma. El objetivo de ASP.net MVC es que es más simple y mejor para webapps que todo el modelo de webforms basado en eventos, y algo que casi todo el mundo fuera del espacio de Microsoft se movió hace años. Microsoft no puede decir eso, porque tienen una gran inversión en formularios web, y es una parte clave de la historia de su empresa.

Dicho esto, si tiene lógica comercial en sus ayudantes, los está utilizando incorrectamente. Básicamente se trata de código subyacente para la lógica de presentación que solo se duplica en varias páginas, y el objetivo es mantener las etiquetas scriptlet en el marcado lo más simple posible.

Siempre que use los ayudantes de la forma en que deberían usarse, sería bastante trivial que los diseñadores aprendan 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.

Answer 2

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

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

Answer 3

Definitivamente no hay nada de malo con los ayudantes. Se usan para mantener sus puntos de vista limpios y declarativos. Hay un dicho que dice algo así como "si hay una declaración" si "en su punto de vista, lo está haciendo mal". Se usan en muchos frameworks MVC prominentes como Ruby On Rails y Cake PHP. Consulte this post. "Purista" o no, los ayudantes son algo bueno y no deben confundirse con malas prácticas o abstracciones con fugas.

Answer 4

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

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

Si bien tengo la mayor consideración por el framework .NET que reduce mi tiempo de desarrollo y facilita mi trabajo, creo firmemente que las vistas deben ser no propietarias.

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