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 desencadena antes del OnLoad?Al crear un control web, debe anular OnLoad o implementar Page_Load
El método OnLoad debe ser el lugar donde se produce 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.
Puede encontrar este article en el ciclo de vida útil de la página de Microsoft.
Aunque está heredando de UserControl, creo que debe evitar los métodos protegidos si no tiene que hacerlo. El Page_Load está allí para que le sea más fácil agregar el código que es específico para su UserControl.
Solo reemplaza OnLoad si necesita control absoluto sobre cuándo (/ if) se desencadena el evento Load (que debería ser raro, IMO).
Es realmente 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.
La anulación del método requiere más conocimiento sobre el ciclo de vida de la página, pero no tiene nada "incorrecto".
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
Creo que es lo mismo. En mi humilde opinión, con eventos, tiene un poco más de flexibilidad, porque puede suceder más de un oyente en su evento.
Creo que hay una diferencia potencialmente significativa en los dos métodos.
Lo que me refiero es la capacidad de tener control sobre la secuencia de ejecución.
Si está anulando, sabe cuándo tendrá lugar la carga de las clases base porque lo está llamando. Esto proporciona más control, pero probablemente sea algo malo, como muchos argumentarán.
Si utiliza 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: "ASP.NET Web Modelo de servidor de control de eventos" (link to the page) Hay algunas afirmaciones útiles como estos:.
Una de las desventajas de la AutoEventWireup atributo es que se requiere que los controladores de eventos de la página tienen nombres específicos, predecibles Este 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 alto volumen de tráfico, el impacto en el rendimiento podría ser significativo.
(AutoEventWireup indicador se enciende tales métodos como Load)
acordaron - Creo que es importante tener una buena comprensión de todo el ciclo de vida. –