¿El código en línea en sus páginas aspx es una buena práctica?

Question

Si utilizo el siguiente código que pierda la capacidad de hacer clic derecho sobre las variables en el código detrás y refactorizar (cambiar el nombre en este caso) que

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

veo esta práctica en todas partes, pero parece extraño para mí como yo ya no puedo obtener errores de 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 muy interesado en saber si las personas piensan que el enfoque anterior es mejor, ya que es lo que siempre ver en sitios de codificación populares y blogs (por ejemplo, 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 se rompe en tiempo de compilación, no de tiempo de ejecución.

Answer 1

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

Podría seguir y seguir sobre la cantidad de principios que 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 que mi código sea lo más modular y sostenible posible.

Answer 2

Se lo conoce como código de spaghetti y muchos programadores lo encuentran objetable ... por otra parte, si usted y los otros desarrolladores de su empresa lo encuentran legible y mantenible, ¿quién soy yo para decirles qué hacer?

segura, sin embargo, el uso incluye para reducir la redundancia (DRY - no repita usted mismo)

Answer 3

Todo depende de usted. A veces el código "spagehetti" es más fácil de mantener que construir/usar un sistema completo de plantillas para algo simple, pero una vez que tienes páginas bastante complicadas, o más específicamente, una vez que comienzas a incluir mucha lógica en la página, puede obtener sucio muy rápido.

Answer 4

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

Answer 5

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

Answer 6

Si lo piensas en términos de desarrollo de plantillas, es aconsejable mantenerlo en la vista, y no en el código subyacente. ¿Qué sucede si se necesita cambiar de un anclaje a un elemento de la lista con discretamente JS para manejar un clic? Sí, este no es el mejor ejemplo, más que eso, y ejemplo.

Siempre trato de pensar en términos de si tengo un diseñador (HTML, CSS, cualquier cosa), qué le haría hacer y qué haría en el código subyacente, y cómo no pisamos cada uno otros dedos de los pies.

Answer 7

Es solo una mala práctica, si no puede encapsularlo bien.

Como todo lo demás, puede crear un código de espagueti desagradable e ilegible, excepto que ahora tiene etiquetas con las que contestar, que por diseño no son las más legibles del mundo.

Trato de mantener un montón de plantillas fuera de hte, pero una encapsulación excesiva, lleva a tener que buscar en 13 lugares diferentes para ver por qué div x no está disparando al cliente, por lo que es un intercambio.

Answer 8

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

Tome su caso como ejemplo, aunque el código detrás parece tener una mejor separación de la preocupación, pero el problema es que no puede separar las preocupaciones tan claramente como desee. Usualmente cuando hacemos el código detrás de las cosas, no estamos construyendo las aplicaciones en el framework MVC. El código detrás del código tampoco es fácil de mantener y probar, al menos cuando se compara con MVC.

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

En suma: el código en línea no es una buena práctica, pero es un mal necesario.

Mi 2cents.

Answer 9

Normalmente uso así.

<a href='<%# DataBinder.Eval(Container.DataItem,"Id",""/Admin/Content/EditResource.aspx?ResourceId={0}") %'>