.net - net - Al crear un control web, debe anular OnLoad o implementar Page_Load
html asp net (8)
A pesar de que heredas de UserControl , creo que debes evitar utilizar los métodos protegidos si no tienes que hacerlo. El Page_Load está allí para facilitarle la adición del código específico de su UserControl .
Solo anule OnLoad si necesita control absoluto sobre cuándo (/ if) se dispara el evento Load (que debería ser raro, IMO).
Cuando crea un nuevo control de usuario web en Visual Studio, de manera predeterminada agrega el evento Page_Load. ¿Cuál es la ventaja de usar esto en lugar de anular el evento base OnLoad en el control? ¿Es solo que el evento Page_Load se dispara antes de OnLoad ?
Como puede ver arriba, en su mayoría se reduce a una elección personal SI esa elección se hace con conocimiento de causa. La mejor visión general rápida pero sólida que he visto está en http://weblogs.asp.net/infinitiesloop/archive/2008/03/24/onload-vs-page-load-vs-load-event.aspx
El método OnLoad debe ser el lugar donde se OnLoad el evento Load . Personalmente siempre trato de manejar el evento a menos que necesite hacer un procesamiento adicional para plantear el evento.
Recomiendo manejar el evento en circunstancias normales.
Es solo una cuestión de elección. Para mí, parece extraño que un objeto adjunte un evento a sí mismo, especialmente cuando hay un método que puede anular.
Creo que el equipo de ASP.NET usó eventos porque ese era el modelo para Global.asa en ASP, y para reducir la barra para los desarrolladores que no entienden la herencia y sobreescriben los métodos virtuales.
Anular el método requiere más conocimiento sobre el ciclo de vida de la página, pero no hay nada "incorrecto" en él.
Puede encontrar útil este artículo en el ciclo de vida de la página de Microsoft.
creo que es lo mismo En mi humilde opinión, con Events, tienes un poco más de flexibilidad, ¡porque puedes pasar más de un oyente a tu evento!
Creo que hay una diferencia potencialmente significativa en los dos métodos.
A lo que me refiero es a la capacidad de tener control sobre la secuencia de ejecución.
Si está anulando, sabe cuándo tendrá lugar la Carga de clases base porque lo está llamando. Esto proporciona más control, pero probablemente sea algo malo, como muchos argumentarán.
Si usa evento, no tiene garantía en términos de orden de llamada. Esto te obliga a escribir el evento Load, que debería ser independiente de lo que las súper clases están haciendo durante la fase de carga. Creo que este sería el enfoque preferido y tal vez es por eso que el código autogenerado por VS es así.
Lea la sección llamada: "Eventos de página de enlace" en la página de MSDN titulada: "Modelo de evento de control de servidor web ASP.NET" ( enlace a la página ). Hay algunas declaraciones útiles como estas:
Una desventaja del atributo AutoEventWireup es que requiere que los manejadores de eventos de la página tengan nombres específicos y predecibles. Esto limita su flexibilidad en la forma de nombrar los controladores de eventos. Otra desventaja es que el rendimiento se ve afectado negativamente , porque ASP.NET busca métodos en tiempo de ejecución. Para un sitio web con altos volúmenes de tráfico, el impacto en el rendimiento podría ser significativo.
(El indicador AutoEventWireup activa métodos tales como Page_Load)