Page_Load или Page_Init - PullRequest
Новая
       19

Page_Load или Page_Init

11 голосов
/ 19 мая 2010

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

$.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 ( Код позади ) 

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. В настоящее время отлично работает в обоих методах, но я просто хочу понять все тонкости выбора одного метода вместо другого

Ответы [ 4 ]

11 голосов
/ 19 мая 2010

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

alt text

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

8 голосов
/ 19 мая 2010

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

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

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

2 голосов
/ 19 мая 2010

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

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

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

0 голосов
/ 19 мая 2010

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

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

...