OnDataBinding vs Inline: pros, contras y overhead

Question

Pensé que haría esta pregunta para ver por qué muchos ejemplos y personas prefieren usar el enlace de datos en línea en el código aspx versus implementar un evento OnDataBinding al usar WebForms.

Para cualquier control de enlace de datos (por ejemplo. Repetidor, GridView, etc) me ha puesto en práctica el método OnDataBinding para los controles sobre el terreno si tengo que hacer nada que no se construye en sacarlo de la caja (por ejemplo. Necesito hacer una evaluación). La mayoría de los ejemplos que veo tienen el código correcto en la página aspx usando la sintaxis en línea <% #.

Ejemplo de código en línea ASP.NET:

<asp:Literal ID="litExample" runat="server" 
    Text='<%# Eval("ExampleField").ToString() %>' /> 

Ejemplo de cómo yo prefiero hacerlo:

En el aspx:

<asp:Literal ID="litExample" runat="server" 
    OnDataBinding="litExample_DataBinding" /> 

En los .cs de código subyacente:

protected void litExample_DataBinding(object sender, System.EventArgs e) 
{ 
    Literal lit = (Literal)(sender); 
    lit.Text = string.Format("{1} - {2}", 
     Eval("ExampleField").ToString(), 
     Eval("ExampleField2").ToString()); 
} 

Personalmente prefiero El método de código subyacente porque mantiene limpias mis páginas aspx y no tengo todo este código en línea por todas partes y el siguiente tipo simplemente sabe que siempre busca en los archivos .cs los cambios de código. La separación de la presentación y el código también se mantiene mejor de esta manera, ya que el HTML es solo para los titulares de posición y el enlace de código determina qué se está controlando realmente.

Ahora estos son ejemplos muy básicos. El campo podría ser un número entero que desea formatear con los 0 iniciales o un DateTime que necesita un formato específico, etc. También podría tomar todo tipo de manipulación y código para obtener el valor finalmente que debe almacenarse en la propiedad 'Texto' en el fin.

¿Dónde dibuja la línea y la mueve al código detrás si está utilizando el código en línea?

¿Cuáles son los pros y los contras para hacerlo de cualquier manera?

¿Se necesita más sobrecarga que la otra?

Editar Nota: No estoy hablando acerca de asignar un valor a un control que está justo en la página, pero uno que está siendo enlazado a datos que ya existe en una plantilla repetidor o plantilla de elementos gridview etc ... Es evidente que una sentarse literalmente en una página que simplemente puede asignar en código.

Editar Nota: Pensé que obtendría más respuesta, especialmente con respecto a la sobrecarga. ¿La mayoría de la gente NO usa los eventos OnDataBinding?

Answer 1

Hay poca diferencia de rendimiento entre ellos. Una expresión de enlace de datos se analiza y se compila a algo así como

control.DataBinding += new EventHandler(ControlDataBinding); 

y también

private void ControlDataBinding(object sender, EventArgs e) { 
    control.Text = Eval("Field"); 
} 

En este caso, el método OnDataBinding no se reemplaza. Se ejecuta el método base Control.OnDataBinding, lo que eleva el evento DataBinding, lo que hace que se ejecute el código anterior.

Al anular OnDataBinding, simplemente está asumiendo el control antes de que se ejecute el código base, y puede establecer usted mismo la propiedad Text (por ejemplo).

---

No me gusta dar respuestas parciales, pero voy a hacerlo esta vez, porque creo que es ordenado, y que me ha salvado recientemente:

me dice que la expresión de enlace de datos se analizan. De hecho, todo el marcado se analiza, el código en C#, VB.NET o cualquier lenguaje que se genere, y estos son compilados en una clase. Cuando se solicita la página, se crea una instancia de esta clase y comienza su ciclo de vida.

Puede encontrar estos archivos de código generados en el disco lo siento, no recuerdo dónde. Lo interesante de ellos es que todavía funcionan, como código.

Por ejemplo, recientemente tuve algunas redes de Infragistics bastante complejas, tuve todo el formato completo y luego descubrí que necesitaba poder configurar el formato en tiempo de ejecución (para obtener el formato correcto en archivos Excel exportados) . Para hacer esto, abrí el archivo fuente (todas las cuadrículas estaban en un solo control de usuario) y pude extraer la configuración de cada cuadrícula en un grupo separado de métodos.

Pude limpiarlos con ReSharper, extraer secuencias de códigos comunes en una clase base y me quedé con un método estático para configurar cada grilla. Pude llamarlos tanto para la configuración inicial como para la configuración de la cuadrícula ficticia utilizada para la exportación a Excel.

Answer 2

Yo prefiero todo lo contrario. Prefiero mantener mi código subyacente limitado al código de procedimiento, y mantener todo mi código declarativo en mi página Aspx. En su ejemplo anterior, el literal es absolutamente declarativo y, por lo tanto, (según mi preferencia) no pertenecería al código subyacente. La funcionalidad mucho más robusta generalmente va en mi código subyacente, y no quiero que mis desarrolladores se vean abrumados por tener que examinar un montón de líneas de inicialización cuando intentan comprenderlo.

Answer 3

En realidad, prefiero usar el aspx para los controles que esperaría unir, como listview, gridview, repetidor y otros controles similares.

Para los otros controles, los establecería en el código subyacente, pero directamente (como parte del proceso que estoy haciendo, en lugar de llamar literal.DataBind o DataBind para toda la página). Si se trata de un control de usuario/personalizado, espero que los llamadores hagan un DataBind, entonces anularía DataBind y establecería los valores.

Dicho esto, normalmente tengo un montón de código fuera del código subyacente, y tengo una llamada a algo así como ShowUser, donde pongo esas asignaciones a los controles (en lugar de establecer una propiedad, hacer un enlace y tener todas esas evaluaciones para controles simples).

Answer 4

Prefiero que lo haga a su manera con OnDataBinding. Puede mantener su código limpio mediante el uso de una región de "Databind" para todas las llamadas OnDataBinding, y puede mantener su marcado limpio al sacar los bloques de código del lado del servidor horrible de allí.

Creo que la mayoría de las personas lo hacen de la manera en línea porque es más fácil de entender y de implementar.

Answer 5

Estoy de acuerdo con caltrop. Me gusta que mi marcado esté limpio y que todo mi código aspx/ascx resida en mis archivos de código subyacente (donde pertenece).

Solo tengo una cosa para agregar.Prefiero no ensuciar mi código con los eventos OnDataBinding() conectados para cada uno de mis controles de datos. En cambio, lo hago todo en el evento OnDataBinding() del Control de usuario que se está incrustando en el control enlazable (como el repetidor en su muestra).

Por ejemplo, en mi control de usuario de código subyacente se encontraría:

protected override void OnDataBinding(EventArgs e) 
{ 
    base.OnDataBinding(e); 

    litExample.Text = Eval("ExampleField") + " - " + Eval("ExampleField2"); 
} 

Desde aquí se pueden establecer las propiedades de todos sus controles o llamar a otros métodos para ajustarlos. Observe cómo, en mi ejemplo, no tuve que realizar el boxeo como lo hizo aquí: Literal lit = (Literal)(sender);

Eso solo debería ahorrarle algo de rendimiento (nanosegundos por supuesto, pero algo vale la pena medir). Lea la sección "Rendimiento" aquí: http://msdn.microsoft.com/en-us/library/yz2be5wk%28v=vs.80%29.aspx

También estoy en guerra con el uso de cadenas en mi código. Hubiera usado variables de cadena const para definir "Campo de ejemplo" y "Campo de ejemplo2" o configurarlas como propiedades públicas en el Control de usuario que luego podría establecer el control/página que contiene según el nombre de columna del objeto de datos que se utilizará estar atado en contra. Esto ofrece más flexibilidad y reutilización del control.

FYI: No necesita llamar a ToString() en Eval, ya que este método ya devuelve una cadena.