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