Page_Load или Page_Init

Давайте возьмем действительно простой пример при использовании jQuery к ajaxify наша страница...

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

и в ASP.NET (часть HTML) страница (только одна строка)

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

и на странице ASP.NET (Code Behind)

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();
    }
}

мой вопрос

Если это

protected void Page_Load(object sender, EventArgs e)

или

protected void Page_Init(object sender, EventArgs e)

Таким образом, мы можем сохранить некоторые миллисекунды, поскольку мы не должны на самом деле обрабатывать события для страницы, или будет Page_Init отсутствие некоторой сортировки метода к тому времени, когда это называют?

P.S. В настоящее время хорошо работает в обоих методах, но я просто хочу понять входы и выходы выбора одного метода по другому

11
задан balexandre 19 May 2010 в 07:21
поделиться

4 ответа

Любой из них будет работать, потому что вы, по сути, отбрасываете жизненный цикл страницы, вызывая response.Clear () и response.End (). Технически вы можете даже пойти дальше, поместив этот код в предварительную визуализацию, и это сработает. Обращаясь к объекту Response, вы, по сути, перескакиваете через заголовок страницы и прерываете его на полпути, чтобы вы могли выполнить гораздо более простую задачу.

Я полагаю, вам просто не нужен жизненный цикл страницы и вы просто хотите вернуть JSON с этой страницы? Если это так, я настоятельно рекомендую реализовать его как универсальный обработчик (ashx). В этом случае вы должны просто использовать context.Request ["limit"] и context.Response.Write в своем методе Process. Преимущество этого заключается в том, что у вас нет всех накладных расходов .NET на подготовку класса страницы и запуск жизненного цикла страницы, а вместо этого вы используете файл, предназначенный для задачи, которую вы выполняете.

Приятно понимать жизненный цикл страницы, как показано в других ответах, но на самом деле вы его вообще не используете, и вам лучше полностью отказаться от класса страницы.

8
ответ дан 3 December 2019 в 05:33
поделиться

Жизненный цикл страницы имеет значение только в контексте элементов страницы (элементов управления), поэтому я не вижу никаких различий в вашем случае, поскольку у вас нет других дочерних элементов управления в вашем страница - это совершенно неважно.

Но вот настоящий вопрос: если у вас нет визуализации html на вашей странице (только сериализация данных), почему вы решили работать с обычной страницей .aspx?

Веб-сервис - идеальный кандидат для этого сценария. И вы будете удивлены, насколько сильно вы улучшите производительность в итоге.

2
ответ дан 3 December 2019 в 05:33
поделиться

Основной жизненный цикл страницы ответит на ваш вопрос Полная статья : http://www.codeproject.com/KB/aspnet/ASPDOTNETPageLifecycle.aspx

alt text

проверьте тот же вопрос ответ : Поведение Page.Request

11
ответ дан 3 December 2019 в 05:33
поделиться

Вы можете очень хорошо использовать метод Page Init. Но если у вас есть элементы управления на вашей странице и вы хотите получить доступ к любому свойству этих элементов управления, тогда лучше использовать событие загрузки страницы, но в вашем случае вам не нужно использовать событие загрузки страницы.

Вы можете просмотреть жизненный цикл страницы Asp.Net здесь , чтобы лучше понять, какое событие использовать.

0
ответ дан 3 December 2019 в 05:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: