asp.net how to avoid repeated delivery of page rearrangement

Some of the user's behavior is really out of the doubt ..., open the Web page something is all right to Refresh you, this action seems harmless, but in the case of just executed Submit, Refresh page will cause repeated execution, this is why in the major shopping site transactions payment action, will prompt " Do not close the Web page or rearrange messages that avoid causing a transaction to fail or repeat transactions, but as a matter of experience, many users still Refresh the page even if they are warned on the Web page.

Note, do not think that only asp.net have this problem, this problem is commonly found in web programs, no matter what platform you use, language development, because the browser will own Cache users browsing behavior (including data), tested IE, FireFox, Chrome are the same, Guess is because this can have the previous page, the next page of the history of the record, as for further discussion, small muscle will no longer delve into (Welcome to understand the predecessors of high Man to guide the maze, said the reason) ... Since the browser has been designed so, and we may never guess how users love to operate, then the development of ASP.net to see how to solve this problem.

I don't know if anyone like me, immediately thought: Redirect, that is, after performing a successful work, the implementation of the Response.Redirect method to redirect to the results page, this is the most typical approach, but this is more suitable for the action of multiple Web Forms, such as: Shopping cart, After the checkout can lead to the order of success of the message page, anyway, from the first step, the second step ... To the checkout screen, and one more guide is not very different. Unfortunately, multiple Web forms are few, most Web programs now require asynchronous updates (AJAX), preferably in the same screen to complete all the action, even if today does not require asynchronous updates, each job is completed after the other Web page, is not ideal, so this practice is not perfect, In addition to the hassle of maintaining a Web page, the fact that users go back to the previous page and then rearrange them is likely to result in repeated execution ....

Before any movement, check to see if the same information exists? In other words, check in the database, it should be feasible, but ... The process seems to be a little cumbersome, to each of the job content individually to write compared to whether there is the same information logic, just want to feel tired ... and sometimes it is really possible to allow the same information exists, such as line boarding service message version, the user does not durable when waiting, will leave a message, the content may be the same as before, This is not the same as the repetition of the data caused by the heavy brush page, so it seems that it is not a good practice to exclude the same information from the database.

The key point is how to distinguish the user is being repainted page, further, there is no once and for all, so that we can check a certain attribute can be judged is not the return of the page, to avoid repeated delivery of action? On second thought: there is nothing new under the sun, search the Internet, a few foreign articles, The discussion series has put forward several solutions to this problem (it has been proved that the previous two methods are also suggested), among which I think the most worth seeing is the bottom two articles:

Build Your asp.net Pages on a richer bedrock

Preventing Duplicate record insertion on Page Refresh

Referring to the contents of the two articles above, the final answer is: We can inherit the asp.net Page category and expand the functionality we need! The practice is as follows:

1, Inherit System.Web.UI.Page, custom a basepage category.

The following are the referenced contents:

Using System;

///

Summary description of BasePage

///

public class BasePage:System.Web.UI.Page

{

Public BasePage () {}

}

2, under the BasePage category to write the Setactionstamp method, the purpose is to store a system time stamp in session.

The following are the referenced contents:

///

Settings stamp

///

private void Setactionstamp ()

{

session["Actionstamp"] = Server.URLEncode (DateTime.Now.ToString ());

}

3, handling the PreRender event, set the stamp at the initial loading time of the Web page, and the stamp will be deposited into the hiddenfield at each load execution.

The following are the referenced contents:

Public BasePage () {this. PreRender + = new EventHandler (Page_PreRender); }

void Page_PreRender (object sender, EventArgs e)

{

if (! IsPostBack)

{

Setactionstamp ();

}

Clientscript.registerhiddenfield ("Actionstamp", session["Actionstamp"). ToString ());

}

4, custom Isrefresh property, by judging whether the HiddenField stored by the stamp is equal to the value of the session stored, you can know whether the Web page through the reorganization of the movement back.

The following are the referenced contents:

///

Gets the value that indicates whether the page is returned via a rearrangement action (postback)

///

protected bool Isrefresh

{

Get

{

If httpcontext.current.request["Actionstamp"] As String = = session["Actionstamp"] as String)

{

Setactionstamp ();

return false;

}

return true;

}

}

After writing a Web page program, as long as derived from the basepage can be obtained Isrefresh property values, can be used to determine whether the Web page is collated, to avoid repeating the previous action:

As far as the concept is concerned: when the page is first loaded we record the time stamp in the session, copy a copy to the HiddenField, and the stamp is always the first set value when the page is repeated, until a certain action we want to be able to tell whether it was sent out by rearrangement, so the Isrefresh attribute to judge, the initial send out of course will return false, the job can be executed smoothly, and only updates the session time stamp, when the value of the different HiddenField. Interesting things come, Refresh the last action once again, but because the browser will Cache state, then HiddenField time stamp is still an older value, different from the session held, check the Isrefresh property value is true, To avoid repetitive execution, you can block the action.

So far, this paper puts forward a solution to the problem raised by the title and simply explains the concept, but the previous two reference articles in fact have detailed elaboration, want to understand people suggest must go to see, especially the first article by Master Dino Esposito (Introduction, personal blog) wrote.

Finally said a Dino master's article has mentioned the small technique, since we have expanded a to have the detection page reorganization function The BasePage class, how to make the new Web Form preset which later joins is derived from the BasePage? can open Web.config file

After the setup is complete, the newly added Web Form will be inherited from BasePage.