Давайте возьмем действительно простой пример при использовании 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. В настоящее время хорошо работает в обоих методах, но я просто хочу понять входы и выходы выбора одного метода по другому
Любой из них будет работать, потому что вы, по сути, отбрасываете жизненный цикл страницы, вызывая response.Clear () и response.End (). Технически вы можете даже пойти дальше, поместив этот код в предварительную визуализацию, и это сработает. Обращаясь к объекту Response, вы, по сути, перескакиваете через заголовок страницы и прерываете его на полпути, чтобы вы могли выполнить гораздо более простую задачу.
Я полагаю, вам просто не нужен жизненный цикл страницы и вы просто хотите вернуть JSON с этой страницы? Если это так, я настоятельно рекомендую реализовать его как универсальный обработчик (ashx). В этом случае вы должны просто использовать context.Request ["limit"] и context.Response.Write в своем методе Process. Преимущество этого заключается в том, что у вас нет всех накладных расходов .NET на подготовку класса страницы и запуск жизненного цикла страницы, а вместо этого вы используете файл, предназначенный для задачи, которую вы выполняете.
Приятно понимать жизненный цикл страницы, как показано в других ответах, но на самом деле вы его вообще не используете, и вам лучше полностью отказаться от класса страницы.
Жизненный цикл страницы имеет значение только в контексте элементов страницы (элементов управления), поэтому я не вижу никаких различий в вашем случае, поскольку у вас нет других дочерних элементов управления в вашем страница - это совершенно неважно.
Но вот настоящий вопрос: если у вас нет визуализации html на вашей странице (только сериализация данных), почему вы решили работать с обычной страницей .aspx?
Веб-сервис - идеальный кандидат для этого сценария. И вы будете удивлены, насколько сильно вы улучшите производительность в итоге.
Основной жизненный цикл страницы ответит на ваш вопрос Полная статья : http://www.codeproject.com/KB/aspnet/ASPDOTNETPageLifecycle.aspx
проверьте тот же вопрос ответ : Поведение Page.Request
Вы можете очень хорошо использовать метод Page Init. Но если у вас есть элементы управления на вашей странице и вы хотите получить доступ к любому свойству этих элементов управления, тогда лучше использовать событие загрузки страницы, но в вашем случае вам не нужно использовать событие загрузки страницы.
Вы можете просмотреть жизненный цикл страницы Asp.Net здесь , чтобы лучше понять, какое событие использовать.