Подтвердить что ты не робот

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(Код ниже)

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

4b9b3361

Ответ 1

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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