Page_Load or Page_Init

Question

Let's take a really simple example on using jQuery to ajaxify our page...

$.load("getOrders.aspx", {limit: 25}, function(data) {
    // info as JSON is available in the data variable
});

and in the ASP.NET (HTML part) page (only one line)

<%@ Page Language="C#" AutoEventWireup="true" 
         CodeFile="getOrders.aspx.cs" Inherits="getOrders" %>

and in the ASP.NET (Code Behind) page

public partial class getOrders : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        string lmt = Request["limit"];
        List<Orders> ords = dll.GetOrders(limit);


        WriteOutput( Newtonsoft.Json.JsonConvert.SerializeObject(ords) );
    }

    private void WriteOutput(string s) 
    {
        Response.Clear();
        Response.Write(s);
        Response.Flush();
        Response.End();
    }
}

my question is

Should it be

protected void Page_Load(object sender, EventArgs e)

or

protected void Page_Init(object sender, EventArgs e)

So we can save some milliseconds as we don't actually need to process the events for the page, or will Page_Init lack of some sorting of a method by the time it is called?

P.S. Currently works fine in both methods, but I just want to understand the ins and outs of choosing one method over the other

Answer 1

Basic page life cycle will answer your question Full article : http://www.codeproject.com/KB/aspnet/ASPDOTNETPageLifecycle.aspx

check same question answer : http://stackoverflow.com/questions/2719554/page-request-behaviour/2719588#2719588

Answer 2

You can very well use the Page Init method. But if you have controls in your page and want to access any property of those controls then better to use the Page load event, but in your case you don't need to use page load event.

You can go through the Asp.Net Page Life cycle here to better understand which event to use.

Answer 3

Either one would work, because you're essentially throwing out the page lifecycle by calling response.Clear() and response.End(). Technically you could even go as far as putting that code in prerender and it would work. By accessing the Response object you're basically going over the head of the page and cutting it off mid-stride so that you can perform a much simpler task.

I assume you simply do not want the page lifecycle at all and simply want to return JSON from this page? If so, I highly recommend implementing it as a Generic Handler (ashx). In this case you'd simply use context.Request["limit"] and context.Response.Write in your Process method. The benefit of doing this is that you don't have all the overheads of .NET preparing the page class and starting the page lifecycle, and are instead using a file intended for the task you're doing.

It is nice to understand the page lifecycle, as shown in other answers, but realistically you're not using it at all and you'd be better off moving away from the page class entirely.

Answer 4

Page life-cycle only has meanings in context of page elements (controls), so i don't see any differences in your case, since you don't have any other child controls in your page - this is totally irrelevant.

But here is the real question: if you don't have any rendering of html in your page (only data serialization), why you have choose to work with regular .aspx page?

Web service is ideal candidate for this scenario. And you'll be surprised how much performance improvement you'll gain in the end.