ASP.NET: ¿código detrás o no código detrás?

Question

¿Por qué alguien querría no usar un código detrás del archivo para que el código del lado del servidor esté separado del marcado? ¿No se suponía que era una de las ventajas de .NET sobre ASP clásico?

Personalmente, creo que mezclar código con marcado hace que el código sea mucho más difícil de entender.

no me gusta ver esas malditas <%%> (servidor bloques cara) entre sí empalmado con marcado, qué asco. Esperaría que esto esté en ASP.NET únicamente por compatibilidad con versiones anteriores con ASP clásico, pero veo ejemplos de MS todo el tiempo que incluyen esos corchetes amarillos.

Estoy tratando de entender un ejemplo de código que está disponible para descargar here y desconcertado por qué cualquiera de mis saltos del lado del servidor here no se rompen al ejecutar el código aunque veo que se ha configurado en la web .config. Como normalmente trabajo con código subyacente, me pregunto si hay algo relacionado con el código del lado del servidor en el aspx que se maneja de manera diferente y que me impide depurar el código runat = server.

So. Mis preguntas son:

1) ¿Por qué alguien querría no usar un código detrás del archivo para que el código del lado del servidor esté separado del marcado?

2) ¿Por qué no podría romper la lógica del servidor?

Su visión y opiniones también son bienvenidas en cualquiera de mis comentarios relacionados.

Answer 1

La capacidad de código en línea usando <% %> no es sólo para compatibilidad con versiones anteriores, pero una característica de .NET que puede permitir un cierto (¡relativamente!) soluciones claras y directas. Sin embargo, a menudo se utiliza de una manera menos que ideal. Del mismo modo, codifique en el código subyacente si a menudo (normalmente de hecho) se usa de una manera menos que ideal, como lo son los controles web.

Tener código en el código subyacente normalmente no sirve para separate concerns, pero tener un código de espagueti desordenado en un lugar diferente del que teníamos en el asp clásico. .NET le permite tener soluciones muy bien organizadas, pero depende de usted hacer que suceda. Tener código en el código detrás de las páginas es no el primer paso en ese viaje, justo donde ese viaje puede comenzar.

cuanto a por qué los acontecimientos no están disparando, lo más probable:

• no es en realidad está activado el evento. (¿Cambia el elemento seleccionado en la lista desplegable para activar realmente ese evento?)
• En realidad, no tiene el evento cableado. En la ventana de propiedades para ese control, ¿está listado el nombre de la función de evento correspondiente al evento en cuestión? (Esta es la manera más directa, también puede usar las maneja keywork en vb, por ejemplo)
• A menudo, cuando mis eventos no se activan, es porque estoy haciendo algo estúpido como no haber iniciado mi código, o mi url está apuntando al lugar equivocado.

Answer 2

1) Supongo que si estás acostumbrado a desarrollar ASP clásico, entonces es una transición fácil.

2) Sin ver su marcado, no podría decirle cuál es su problema. Si no está golpeando punto de interrupción que, podría ser una de varias razones:

1. depuración puede estar desactivada
2. El evento no tiene lugar
3. no hay nada en su margen de beneficio le comunica al control de que su método está allí como un controlador para el evento.

Answer 3

Muy a menudo el código ASP.NET de "muestra" se distribuye con código en línea simplemente porque, bueno, es más fácil distribuirlo de esa manera. Es autónomo, puede copiarlo y pegarlo en el bloc de notas, guardarlo como .aspx en la carpeta de un sitio de prueba y ver cómo se ejecuta. Probablemente no sea algo que quieras hacer en producción.

En cuanto a la pregunta más general ... ASP.NET MVC es técnicamente todavía ASP.NET y no utiliza archivos de código subyacente. Muchos desarrolladores creen que los archivos de código subyacente simplemente intercambian un tipo de fealdad por otro; Personalmente, puedo verlo desde ambos lados, pero creo que la verdadera razón de tanto código malicioso en ASP clásico no era la sopa de etiquetas, sino el hecho de que la gente estaba haciendo cosas locas en el código de "vista" como abrir conexiones de bases de datos. . Mientras no hagas ese tipo de cosas, algunas etiquetas de servidor no son un gran problema.

De hecho, si haces un enlace de datos vas a tener un montón de etiquetas Eval y Bind mezcladas con el marcado. Así que incluso WebForms puros con código subyacente no siempre son impecables.

Answer 4

Los corchetes utilizados en la mayoría de los ejemplos de MS suelen ser para llamadas a funciones o para hacer referencia a un enlazador de datos.

Por ejemplo, <%# Databinder.Eval("MyColumn") %> se usaría en un repetidor.

También son etiquetas que se utilizan para hacer referencia a los atributos web.config como la cadena de conexión <%$ConnectionStrings:NorthwindConnection %>

Answer 5

2) ¿Por qué podría no ser capaz de romper la lógica unilateral del servidor?

Es posible que la creación falle cuando comenzó la depuración, y no notó la elección de ejecutar la compilación anterior. Sus puntos de ruptura pueden no haber existido en esa construcción.

Answer 6

<%# DataBinder.Eval("Column") %> puede ahorrarle un montón de código adicional del código que está detrás, y no es tan malo como una práctica en mi opinión.