如何避免生命周期黑客攻击？ [英] How to avoid lifecycle hacks?

问题描述

ASP.NET模型被吹捧为开发网页的一种干净的OO方法，

但有时页面生命周期构成了愚蠢的障碍，迫使你恢复到b $ b Olde ASP 3.0方式。


这里是ASPX页面的大致轮廓：


....一堆标准控件。 ..

PagingNav

ResultSetDisplay

SubmitButton


基本上，PagingNav允许用户导航通过DB结果

set; ResultSetDisplay显示数据列表中当前选定的页面;

和SubmitButton用于用户更改条件并希望

更新视图。


现在，PagingNav控件需要知道数据库中找到的记录总数

，因此查询必须在呈现之前被激活。因此我需要在PagingNav的PreRender事件之前执行查询，其中

表示我不能，例如，在

ResultSetDisplay控件，因为它将在PagingNav控件的PreRender事件后执行

（由于它在页面中的位置）。换句话说，

对于PageNavControl来说，找出查询找到的总记录数太晚了。我可以在PreRender之前触发的ResultSetDisplay

的任何事件中执行查询。到目前为止一直很好。


输入SubmitButton控件，这会搞乱整个计划。问题

是，我想在这个按钮被点击的时候将当前页码重置为1。所以我在其SubmitButton_Click中添加代码来做到这一点。唉，这个事件

在ResultSetDisplay的Load事件之后执行，并且在它的

PreRender事件之前执行。这意味着让ResultSetDisplay显示

适当的页面（即＃1），我必须在SubmitButton_Click事件之后发生

的事件中执行查询，这是PreRender事件。

但是这几乎搞砸了PagingNav控件，因为如上面所解释的那样，它需要找出查询找到的记录数，但是现在已经很晚了。


所以，为了解决这个问题，我必须恢复到ASP 3.0 hacks并添加一些东西
在ResultSetDispay的Load事件中
，例如：


if（Request.Form [" update"]！= null）

this .currentPage = 1;


这完全违背了ASP.NET的OO风格。


所以我的问题是，你们怎么样？整齐地解决这个问题？

解决方案

我会创建一个基础页面类并从此类派生我的页面。

基页的Page_Load事件将首先触发，然后您可以在此处点击您的数据

访问权限和业务逻辑层。检索您需要的数据和

设置派生类的自定义属性，以便在渲染之前进行检查。


我还建议在OOP上购买一些书并研究它们小心。

您尝试使用几乎自上而下的方法解决问题。当你想要实现一个OO设计时，你知道你走错了路径

当你试图在事后做好准备时。总是试着想一下

会先出现什么。在这种情况下，基类将解决您的问题，并且
也使您的代码更加优雅和可扩展。祝好运！ Ken。


-

Ken Dopierala Jr.

对于优秀的ASP.Net网站托管尝试：
< a rel =nofollowhref =http://www.webhost4life.com/default.asp?refid=Spinlighttarget =_ blank> http://www.webhost4life.com/default.asp?refid=Spinlight

如果您在我这里注册并需要帮助，请给我发电子邮件。


" Homam" <何*** @ discussions.microsoft.com>在消息中写道

新闻：A2 ********************************** @ microsof t.com ...

ASP.NET模型被吹捧为开发web
页面的干净OO方法，但有时页面生命周期构成了愚蠢的障碍，迫使你
恢复到Olde ASP 3.0的方式。

这是一个ASPX页面的大致轮廓：

......一堆标准控件......
PagingNav
ResultSetDisplay
SubmitButton

基本上，PagingNav允许用户浏览数据库结果
设置; ResultSetDisplay显示数据
列表中当前选定的页面;如果用户更改了标准并希望
更新视图，则使用SubmitButton。

现在，PagingNav控件需要知道找到的记录总数
DB，因此查询必须在呈现之前被激活。因此我必须在PagingNav的PreRender事件之前执行查询，这意味着我不能，例如，在
的PreRender事件中执行ResultSetDisplay控件的查询，因为它将被执行在PagingNav控件的PreRender
事件之后（由于它在页面中的位置）。在其他
字样中，PageNavControl计算查询找到的总
记录为时已晚。我可以在任何在PreRender之前触发的ResultSetDisplay
中执行查询。到目前为止一直很好。

输入SubmitButton控件，这会搞乱整个计划。
问题是，我想在点击这个按钮时将当前页码重置为1。所以我在其SubmitButton_Click中添加代码来做到这一点。唉，这个
事件在ResultSetDisplay的Load事件之后执行，并且在它的PreRender事件之前执行。这意味着要让ResultSetDisplay显示相应的页面（即＃1），我必须在SubmitButton_Click事件发生后发生的事件中执行查询，即PreRender
事件。但这几乎搞砸了PagingNav控件，因为正如上面解释的那样，它需要找出查询找到的记录数，但现在太晚了。
，例如：

if（Request.Form ["]更新"]！= null）
this.currentPage = 1;

这完全违背了ASP.NET的OO风格。

所以我的问题是，你们怎么能整齐地解决这个问题？

嗨Homan：


这是一种方法：


将所有查询代码从PreRender和事件处理程序中分解为
到类的不同方法，比如PopulateDataList。如果我了解您的情况，您可能需要将页码传递给

方法。


在第一个Page_Load事件期间（！IsPostBack）你最初可以通过调用这个方法来填充数据列表。同样，提交

按钮点击事件可以调用此方法传递页码

1.


我可能不会了解你使用

分页导航时遇到的问题。我认为这个导航控件会激活事件

调用PopulateDataList传递正确的页码。

PopulateDataList也可以通知导航控件有关总数

记录数。所有这一切都发生在控件呈现之前，并且

让你无法在PreRender中获得必须理解页面上发生的事情的内容。


-

Scott
http://www.OdeToCode.com/blogs/scott/

2005年3月2日星期三17:57:03 -0800，Homam

< Ho *** @ discussion.microsoft.com>写道：

ASP.NET模型被吹捧为开发网页的一种干净的OO方法，但有时候页面生命周期构成了愚蠢的障碍，迫使你回复 Olde ASP 3.0方式。

这是一个ASPX页面的大致轮廓：

...一堆标准控件......
PagingNav
ResultSetDisplay
SubmitButton

基本上，PagingNav允许用户浏览数据库结果
设置; ResultSetDisplay显示数据列表中当前选定的页面;
和SubmitButton用于用户更改条件并想要更新视图的情况。

现在，PagingNav控件需要知道数据库中找到的记录总数，因此查询必须在呈现之前进行处理。因此我必须在PagingNav的PreRender事件之前执行查询，这意味着我不能，例如，在ResultSetDisplay控件的PreRender事件中执行查询，因为它将被执行在PagingNav控件的PreRender事件之后（由于它在页面中的位置）。换句话说，对于PageNavControl来说，找出查询找到的总记录为时已晚。我可以在任何在PreRender之前触发的ResultSetDisplay
中执行查询。到目前为止一直很好。

输入SubmitButton控件，这会搞乱整个计划。问题
是，我想在点击这个按钮时将当前页码重置为1。所以我在其SubmitButton_Click中添加代码来做到这一点。唉，此事件
在ResultSetDisplay的Load事件之后执行，并在其PreRender事件之前执行。这意味着让ResultSetDisplay显示相应的页面（即＃1），我必须在SubmitButton_Click事件（即PreRender事件）之后发生的事件中执行查询。但是，这几乎搞砸了PagingNav控件，因为正如上面解释的那样，它需要找出查询找到的记录数，但现在太晚了。

所以，为了解决这个问题，我必须恢复到ASP 3.0黑客并在ResultSetDispay的Load事件中添加一些东西
，如：

if（Request.Form [ " update"]！= null）
this.currentPage = 1;

这完全违背了ASP.NET的OO风格。

所以我的问题是，你们怎么能整齐地解决这个问题？

嗨肯，


这不会解决我的问题，因为即使我添加一个中间的
类，重载的Load事件仍然会在SubmitButton之前触发的

Click事件。因此，如果用户点击该按钮更新条件，那么当查询已经执行后，当前页面将被设置，并且

ResultSetDisplay将显示错误的页面。


为了说明，让我们说用户提交了一组标准C1和

浏览到其结果集的第5页。然后他将标准

更改为C2并点击SubmitButton。现在，如果我在派生类中的重载

Load事件处理程序中执行查询，查询将检索

C2的第5页，而不是页面1，因为它应该是，因为查询执行后，页面在SubmitButton

事件处理程序中设置。


顺便说一句，代码在Code Behind类中执行，从页面中得出

。


我非常精通OOA / D / P和所有设计模式的用具（我
来自J2EE背景），但我仍然想弄清楚ASP.NET的'b $ b管道。


感谢您的反馈。



Ken Dopierala Jr.写道：

我会创建一个基页类，并从这个类派生我的页面。
基页的Page_Load事件将首先触发，然后您可以在此处点击您的数据访问和业务逻辑层。检索您需要的数据并设置派生类的自定义属性，以便在渲染之前进行检查。

我还建议您购买一些关于OOP的书籍并仔细研究它们。
您尝试过使用几乎自上而下的方法解决您的问题。当你试图实施OO设计时，你知道你在错误的道路上
当你试图在事后做好准备。总是试着想一想
会先出现什么。在这种情况下，基类将解决您的问题，并使您的代码更加优雅和可扩展。祝好运！ Ken。

- Ken Dopierala Jr.
对于伟大的ASP.Net网站托管尝试：
http://www.webhost4life.com/default.asp?refid=Spinlight
如果您注册在我的帮助下，请给我发电子邮件。

Homam <何*** @ discussions.microsoft.com>在消息中写道
新闻：A2 ********************************** @ microsof t.com。 .. 的ASP.NET模型被吹捧为一个干净的面向对象的方法来开发Web
页面，但有时页面生命周期带来傻强迫你的障碍

将

恢复为Olde ASP 3.0方式。

这是ASPX页面的大致轮廓：

......一堆标准控件......
PagingNav
ResultSetDisplay
SubmitButton

基本上，PagingNav允许用户浏览DB结果
设置;所述ResultSetDisplay显示当前选择的页在数据

列表; 和提交按钮被用于在情况下，用户改变标准和希望

到

更新视图。
现在，PagingNav控件需要知道在数据库中找到的记录总数，所以查询必须在它之前被激活'已呈现。因此我必须在PagingNav的PreRender事件之前执行查询，这意味着我不能，例如，在

的PreRender事件中执行查询

ResultSetDisplay控件，因为它将在PagingNav控件的PreRender

事件

之后执行（由于它在页面中的位置）。在其它

即，这将是太迟了PageNavControl找出总
记录查询找到了。我可以在任何在PreRender之前触发的ResultSetDisplay
中执行查询。到目前为止一直很好。

输入SubmitButton控件，这会搞乱整个计划。

问题

是，我想在点击此按钮时将当前页码重置为1。所以我在其SubmitButton_Click中添加代码来做到这一点。唉，这个

事件

在ResultSetDisplay的Load事件之后执行，并且在它的PreRender事件之前执行。这意味着要让ResultSetDisplay显示相应的页面（即＃1），我必须在SubmitButton_Click事件（即PreRender

）之后发生的事件中执行查询。
事件。

但是这几乎搞砸了PagingNav控件，因为如上所述，它需要找出查询找到多少条记录，但它是现在也很晚了。

所以，为了解决这个问题，我必须恢复到ASP 3.0 hacks并添加

在ResultSetDispay的Load事件中如：（Request.Form [" update"]！= null）
this.currentPage = 1;
这完全违背了ASP.NET的OO风格。

所以我的问题是，你们怎么能整齐地解决这个问题呢？

The ASP.NET model is touted as a clean OO approach to developing web pages,
yet sometimes the page lifecycle poses silly obstacles that forces you revert
to the Olde ASP 3.0 Ways.

Here''s a rough outline of an ASPX page:

.... a bunch of criteria controls...
PagingNav
ResultSetDisplay
SubmitButton

Basically, the PagingNav allows the user to navigate through the DB result
set; the ResultSetDisplay shows the currently selected page in a data list;
and the SubmitButton is used in case the user changed criteria and wants to
update the view.

Now, the PagingNav control needs to know the total number of records found
in the DB, so the query must be exectued before it''s rendered. Therefore I
have to execute the query before the PreRender event of PagingNav, which
means I cannot, for example, execute the query in the PreRender event of the
ResultSetDisplay control since it will be executed after the PreRender event
of the PagingNav control (due to its position in the page). In other words,
it would be too late for the PageNavControl to figure out the total records
the query found. I can execute the query in any event of ResultSetDisplay
that fires before PreRender. So far so good.

Enter the SubmitButton control, which messes up the whole plan. The problem
is, I want to reset the current page number to 1 whenever this button is
clicked. So I add code to do that in its SubmitButton_Click. Alas, this event
executes AFTER the Load event of the ResultSetDisplay and BEFORE its
PreRender event. This means to get the ResultSetDisplay to dispay the
appropriate page (i.e. # 1), I have to excute the query in an event that
takes place after the SubmitButton_Click event, which is the PreRender event.
But that pretty much screws up the PagingNav control since, as explained
above, it needs to find out how many records the query found, but it''s too
late now.

So, to fix the problem, I have to revert to ASP 3.0 hacks and add something
in the Load event of the ResultSetDispay such as:

if (Request.Form["update"] != null)
this.currentPage = 1;

which is totally against the OO style of ASP.NET.

So my question is, how would you guys solve such a problem neatly?

解决方案

Hi,

I would create a base page class and derive my pages from this class. The
base page''s Page_Load event will fire first, you can then hit your data
access and business logic layers here. Retrieving the data you need and
setting custom properties for derived classes to check before they render.

I would also recommend buying some books on OOP and studying them carefully.
You attempted to solve your problem using an almost top-down approach. When
you are trying to implement an OO design you know you are on the wrong path
when you try to rig things up after the fact. Always try to think what
would come first. In this case a base class will solve your problem and
also make your code much more elegant and extensible. Good luck! Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

"Homam" <Ho***@discussions.microsoft.com> wrote in message
news:A2**********************************@microsof t.com...

The ASP.NET model is touted as a clean OO approach to developing web pages, yet sometimes the page lifecycle poses silly obstacles that forces you revert to the Olde ASP 3.0 Ways.

Here''s a rough outline of an ASPX page:

... a bunch of criteria controls...
PagingNav
ResultSetDisplay
SubmitButton

Basically, the PagingNav allows the user to navigate through the DB result
set; the ResultSetDisplay shows the currently selected page in a data list; and the SubmitButton is used in case the user changed criteria and wants to update the view.

Now, the PagingNav control needs to know the total number of records found
in the DB, so the query must be exectued before it''s rendered. Therefore I
have to execute the query before the PreRender event of PagingNav, which
means I cannot, for example, execute the query in the PreRender event of the ResultSetDisplay control since it will be executed after the PreRender event of the PagingNav control (due to its position in the page). In other words, it would be too late for the PageNavControl to figure out the total records the query found. I can execute the query in any event of ResultSetDisplay
that fires before PreRender. So far so good.

Enter the SubmitButton control, which messes up the whole plan. The problem is, I want to reset the current page number to 1 whenever this button is
clicked. So I add code to do that in its SubmitButton_Click. Alas, this event executes AFTER the Load event of the ResultSetDisplay and BEFORE its
PreRender event. This means to get the ResultSetDisplay to dispay the
appropriate page (i.e. # 1), I have to excute the query in an event that
takes place after the SubmitButton_Click event, which is the PreRender event. But that pretty much screws up the PagingNav control since, as explained
above, it needs to find out how many records the query found, but it''s too
late now.

So, to fix the problem, I have to revert to ASP 3.0 hacks and add something in the Load event of the ResultSetDispay such as:

if (Request.Form["update"] != null)
this.currentPage = 1;

which is totally against the OO style of ASP.NET.

So my question is, how would you guys solve such a problem neatly?

Hi Homan:

Here is one approach:

Factor all the querying code out of the PreRender and event handlers
into a distinct method of the class, say, PopulateDataList. If I
understand your scenario you might need to pass a page number to the
method.

During the first Page_Load event (!IsPostBack) you can initially
populate the data list by calling this method. Likewise, the submit
button click event could invoke this method passing a page number of
1.

What I may not understand is the problem you are having with the
paging navigation. I''d think this navigation control would fire events
that call PopulateDataList passing the proper page number.
PopulateDataList could also inform the nav control about the total
number of records. All of this happens before the controls render and
gets you out of having code inside PreRender that has to understand
what has happened on the page.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Wed, 2 Mar 2005 17:57:03 -0800, "Homam"
<Ho***@discussions.microsoft.com> wrote:

The ASP.NET model is touted as a clean OO approach to developing web pages,
yet sometimes the page lifecycle poses silly obstacles that forces you revert
to the Olde ASP 3.0 Ways.

Here''s a rough outline of an ASPX page:

... a bunch of criteria controls...
PagingNav
ResultSetDisplay
SubmitButton

Basically, the PagingNav allows the user to navigate through the DB result
set; the ResultSetDisplay shows the currently selected page in a data list;
and the SubmitButton is used in case the user changed criteria and wants to
update the view.

Now, the PagingNav control needs to know the total number of records found
in the DB, so the query must be exectued before it''s rendered. Therefore I
have to execute the query before the PreRender event of PagingNav, which
means I cannot, for example, execute the query in the PreRender event of the
ResultSetDisplay control since it will be executed after the PreRender event
of the PagingNav control (due to its position in the page). In other words,
it would be too late for the PageNavControl to figure out the total records
the query found. I can execute the query in any event of ResultSetDisplay
that fires before PreRender. So far so good.

Enter the SubmitButton control, which messes up the whole plan. The problem
is, I want to reset the current page number to 1 whenever this button is
clicked. So I add code to do that in its SubmitButton_Click. Alas, this event
executes AFTER the Load event of the ResultSetDisplay and BEFORE its
PreRender event. This means to get the ResultSetDisplay to dispay the
appropriate page (i.e. # 1), I have to excute the query in an event that
takes place after the SubmitButton_Click event, which is the PreRender event.
But that pretty much screws up the PagingNav control since, as explained
above, it needs to find out how many records the query found, but it''s too
late now.

So, to fix the problem, I have to revert to ASP 3.0 hacks and add something
in the Load event of the ResultSetDispay such as:

if (Request.Form["update"] != null)
this.currentPage = 1;

which is totally against the OO style of ASP.NET.

So my question is, how would you guys solve such a problem neatly?

Hi Ken,

This wouldn''t slove my problem because even when I add an intermediate
class, the overloaded Load event will still fire before the SubmitButton''s
Click event. So if the user clicked on that button to update the criteria,
the current page will be set AFTER the query has already executed, and the
ResultSetDisplay will display the wrong page.

To illustrate, let''s say that the user submitted a set of criteria C1 and
browsed to page number 5 of the its result set. Then he changed the criteria
to C2 and hit the SubmitButton. Now if I execute the query in the overloaded
Load event handler in the derived class, the query will retrieve page 5 of
C2, not page 1 as it should, because the page was set in the SubmitButton
event handler after the query got executed.

By the way, the code is executed in the Code Behind class, which is derived
from Page anyway.

I''m very well versed in OOA/D/P and all the design patterns paraphernalia (I
come from a J2EE background), but I''m still trying to figure out ASP.NET''s
plumbing.

Thanks for your feedback.


"Ken Dopierala Jr." wrote:

Hi,

I would create a base page class and derive my pages from this class. The
base page''s Page_Load event will fire first, you can then hit your data
access and business logic layers here. Retrieving the data you need and
setting custom properties for derived classes to check before they render.

I would also recommend buying some books on OOP and studying them carefully.
You attempted to solve your problem using an almost top-down approach. When
you are trying to implement an OO design you know you are on the wrong path
when you try to rig things up after the fact. Always try to think what
would come first. In this case a base class will solve your problem and
also make your code much more elegant and extensible. Good luck! Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

"Homam" <Ho***@discussions.microsoft.com> wrote in message
news:A2**********************************@microsof t.com...

The ASP.NET model is touted as a clean OO approach to developing web

pages,

yet sometimes the page lifecycle poses silly obstacles that forces you

revert

to the Olde ASP 3.0 Ways.

Here''s a rough outline of an ASPX page:

... a bunch of criteria controls...
PagingNav
ResultSetDisplay
SubmitButton

Basically, the PagingNav allows the user to navigate through the DB result
set; the ResultSetDisplay shows the currently selected page in a data

list;

and the SubmitButton is used in case the user changed criteria and wants

to

update the view.

Now, the PagingNav control needs to know the total number of records found
in the DB, so the query must be exectued before it''s rendered. Therefore I
have to execute the query before the PreRender event of PagingNav, which
means I cannot, for example, execute the query in the PreRender event of

the

ResultSetDisplay control since it will be executed after the PreRender

event

of the PagingNav control (due to its position in the page). In other

words,

it would be too late for the PageNavControl to figure out the total

records

the query found. I can execute the query in any event of ResultSetDisplay
that fires before PreRender. So far so good.

Enter the SubmitButton control, which messes up the whole plan. The

problem

is, I want to reset the current page number to 1 whenever this button is
clicked. So I add code to do that in its SubmitButton_Click. Alas, this

event

executes AFTER the Load event of the ResultSetDisplay and BEFORE its
PreRender event. This means to get the ResultSetDisplay to dispay the
appropriate page (i.e. # 1), I have to excute the query in an event that
takes place after the SubmitButton_Click event, which is the PreRender

event.

But that pretty much screws up the PagingNav control since, as explained
above, it needs to find out how many records the query found, but it''s too
late now.

So, to fix the problem, I have to revert to ASP 3.0 hacks and add

something

in the Load event of the ResultSetDispay such as:

if (Request.Form["update"] != null)
this.currentPage = 1;

which is totally against the OO style of ASP.NET.

So my question is, how would you guys solve such a problem neatly?

这篇关于如何避免生命周期黑客攻击？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！