Pregunta

Si uso el siguiente código, pierdo la capacidad de hacer clic derecho en las variables en el código subyacente y refactorizarlas (cambiarles el nombre en este caso).

<a href='<%# "/Admin/Content/EditResource.aspx?ResourceId=" + Eval("Id").ToString() %>'>Edit</a>

Veo esta práctica en todas partes, pero me parece extraña porque ya no puedo obtener errores en tiempo de compilación si cambio el nombre de la propiedad.Mi enfoque preferido es hacer algo como esto.

<a runat="server" id="MyLink">Edit</a>

y luego en el código detrás

MyLink.Href= "/Admin/Content/EditResource.aspx?ResourceId=" + myObject.Id;

Estoy realmente interesado en saber si la gente piensa que el enfoque anterior es mejor, ya que eso es lo que siempre veo en blogs y sitios de codificación populares (p. ej.Scott Guthrie) y es un código más pequeño, pero tiendo a usar ASP.NET porque está compilado y prefiero saber si algo está roto en tiempo de compilación, no en tiempo de ejecución.

¿Fue útil?

Solución

No lo llamaría una mala práctica (algunos no estarían de acuerdo, pero ¿por qué nos dieron esa opción en primer lugar?), pero diría que mejorará la legibilidad y el mantenimiento generales si no se somete a esta práctica.Ya transmitió un buen punto, y es la limitación de las funciones IDE (es decir, inspección en tiempo de diseño, advertencia en tiempo de compilación, etc.).

Podría seguir y seguir sobre cuántos principios viola (reutilización de código, separación de preocupaciones, etc.), pero puedo pensar en muchas aplicaciones que rompen casi todos los principios, pero aún funcionan después de varios años.Por mi parte, prefiero hacer que mi código sea lo más modular y fácil de mantener posible.

Otros consejos

Se conoce como código espagueti y muchos programadores lo encuentran objetable...por otra parte, si usted y los demás desarrolladores de su empresa lo encuentran legible y fácil de mantener, ¿quién soy yo para decirle qué hacer?

Sin embargo, seguro que utiliza incluye para reducir la redundancia (DRY, no lo repita)

Lo uso sólo ocasionalmente y generalmente por alguna razón particular.Siempre seré un desarrollador más feliz con mi código completamente separado de mi formato HTML.Es una preferencia personal, pero yo diría que es una mejor práctica.

Tu decides.A veces, el código "spagehetti" es más fácil de mantener que crear/usar un sistema completo de plantillas para algo simple, pero una vez que obtienes páginas bastante complicadas, o más específicamente, una vez que comienzas a incluir mucha lógica en la página misma, puede volverse se ensucia muy rápido.

Creo que es interesante que más asp.net requiera código en las páginas aspx.La vista de lista en 3.5, e incluso ASP.NET MVC.Básicamente, MVC no tiene código detrás, pero sí código en las páginas para representar información.

Si lo piensa en términos de desarrollo de plantillas, entonces es aconsejable mantenerlo en la vista y no en el código subyacente.¿Qué sucede si es necesario cambiar de un ancla a un elemento de lista con JS discreto para manejar un clic?Sí, este no es el mejor ejemplo, sino sólo eso, un ejemplo.

Siempre trato de pensar en términos de si tuviera un diseñador (HTML, CSS, cualquier cosa), qué lo tendría que hacer y qué estaría haciendo en el código subyacente, y cómo no pisarnos los pies unos a otros.

Sólo es una mala práctica si no puedes resumirla bien.

Como todo lo demás, puedes crear código espagueti desagradable e ilegible, excepto que ahora tienes etiquetas con las que contentarte, que por diseño no son las cosas más legibles del mundo.

Intento mantener toneladas de if fuera de la plantilla, pero una encapsulación excesiva me lleva a tener que buscar en 13 lugares diferentes para ver por qué div x no se activa al cliente, por lo que es una compensación.

No lo es, pero a veces es un mal necesario.

Tome su caso como ejemplo, aunque el código subyacente parece tener una mejor separación de preocupaciones, pero el problema es que es posible que no separe las preocupaciones tan claramente como desea.Por lo general, cuando hacemos el código detrás de las cosas, no estamos creando las aplicaciones en el marco MVC.El código detrás del código tampoco es fácil de mantener y probar de todos modos, al menos en comparación con MVC.

Si está creando aplicaciones ASP.NET MVC, creo que seguramente se quedará atrapado con el código en línea.Pero construir en el patrón MVC es la mejor manera de hacerlo en términos de mantenibilidad y capacidad de prueba.

Para resumir:El código en línea no es una buena práctica, pero es un mal necesario.

Mis 2 centavos.

Normalmente lo uso así.

<a href='<%# DataBinder.Eval(Container.DataItem,"Id",""/Admin/Content/EditResource.aspx?ResourceId={0}") %'>
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top