Pourquoi Visual Studio vous propose-t-il nécessairement Page_Load for WebForms?

Question

Lors de la création d'un nouveau formulaire Web, Visual Studios crée un gestionnaire Page_Load dans le code par défaut, ce qui est cool. Donc, pendant des années, j'ai toujours mis du code pour faire des choses comme définir les propriétés des contrôles dans Page_Load. Récemment, j'ai utilisé Reflector pour regarder certains assemblages écrits par Microsoft et j'ai vu qu'ils avaient mis le même type de logique dans une méthode appelée OnLoad (qui soulève soi-disant l'événement load). J'ai donc commencé à me demander, où est le meilleur endroit pour définir les propriétés des contrôles, dans OnLoad ou Page_Load? Ou dans une autre méthode? Et si pas Page_Load, pourquoi Studio ajoute-t-il cela au code derrière?

Ma dernière pensée: Bien que je sache que la mise en logique OnLoad fonctionne très bien, je vais probablement rester avec Page_Load pour l'instant parce que ce classique. J'ai vraiment posé la question pour savoir si j'avais raté quelque chose de nouveau après avoir vu OnLoad apparaître dans le code d'autres personnes. Merci à tous pour vos réponses réfléchies!

Answer 1

Page_Load est juste l'autoeventwireup pour OnLoad. On pourrait penser que cela ne fait aucune différence, mais je suis d'accord avec K. Scott Allen at Ode to Code que vous ne devriez normalement dévier de la norme que lorsque vous essayez de faire quelque chose d'inattendu. Remplacer une méthode virtuelle comme OnLoad suggère que vous essayez de faire quelque chose de différent, par exemple ne pas appeler base.Onload, ce que la plupart des programmeurs ne sont généralement pas.

Answer 2

Vous ne voulez pas utiliser OnLoad, la raison pour laquelle ils l'utilisent est qu'il s'agit d'un wrapper pour déclencher l'événement Page_Load. Ils mettent de la logique là parce qu'ils ne gèrent pas l'événement Page_Load.

En bref, continuez à utiliser Page_Load.

Answer 3

Généralement, les méthodes OnX sont des méthodes qui déclenchent l'événement X. Elles sont un peu comme les gestionnaires d'événements internes de la classe. Cela signifie que lorsque vous codez une classe qui, entre autres choses, détecte un certain événement, vous appelez généralement une méthode qui: 1. fait ce que votre classe doit faire dans ce cas, 2. déclenche l'événement externe.

Je crois que l'une des principales raisons pour lesquelles cela s'est accroché était que, dans la situation actuelle, vous ne pouvez pas simplement appeler le délégué d'événement pour déclencher un événement, vous devez toujours vérifier si ce délégué est nul. Donc vous voulez encapsuler cette vérification dans une méthode. En bref, à moins que vous n'écriviez votre propre classe avec un événement Load, vous n'avez pas besoin de penser à une méthode OnLoad.

Answer 4

Tous les points très valables jusqu'à présent. Mais ne laissez pas ces gars vous effrayer. Vous ne blesserez rien si vous voulez utiliser la méthode OnLoad. N'oubliez pas d'appeler base.OnLoad().

Answer 5

En effet, si vous revenez aux mauvais vieux jours de développement ASP.Net 1.1, vous voyez réellement le câblage en se déroulant, créé pour vous dans chaque page:

#region Web Form Designer generated code 
    override protected void OnInit(EventArgs e) 
    { 
     InitializeComponent(); 
     base.OnInit(e); 
    } 

    /// <summary> 
    /// Required method for Designer support - do not modify 
    /// the contents of this method with the code editor. 
    /// </summary> 
    private void InitializeComponent() 
    {  
     this.Load += new System.EventHandler(this.Page_Load); 
    } 
    #endregion 

Et maintenant tous les et puis, je ferais quelque chose qui a causé VS pour enlever cette petite ligne dans le InitializeComponent, et n'a pas pu établir pourquoi ma page a cessé de faire n'importe quoi.