About PostBack)

For PostBack, I have also written a blog titled deep understanding _ dopostback. In this article, I have made some research on PostBack. It seems that the research is not in-depth enough. However, in principle, the General Web controls in ASP. NET webform (why? Because a few controls such as button do not call the _ dopostback method) when sending a request to the server, the _ dopostback method is called, submit a request to the server by submitting a form. The Web event model provided by webform is also based on the _ dopostback method, two implicit variables (_ eventtarget ,__ eventargument) transmitted to the server) this is the basis for the delivery of PostBack events. _ Eventtarget stores the ID of the control that sends a PostBack request to the server. ASP. NET can find the server-side control instance of its object based on this ID. _ Eventargument stores some parameters of the current PostBack. What other conditions do PostBack require?

In some discussions about webform and MVC some time ago, it was mentioned that if viewstate is disabled, PostBack cannot be used. This also reminds me of the close relationship between viewstate and PostBack. In most cases, if the control state is dynamically maintained. For example, the dropdownlist items is added through the following code:

   1: protected void Page_Load(object sender, EventArgs e)

   2: {

   3:     if (!this.IsPostBack)

   4:     {

   5:         DropDownList1.Items.Add(new ListItem("1", "Value1"));

   6:         DropDownList1.Items.Add(new ListItem("2", "Value2"));

   7:     }

   8: }

Instead of static Addition on the HTML page (or addition before the oninit event, the ispostback judgment cannot be added), if viewstate is disabled, the selectedindexchanged event of dropdownlist will not be triggered normally, the items in the dropdownlist will be cleared. Therefore, to use PostBack, viewstate cannot be disabled.

In addition, PostBack has some shortcomings:

1) After the page is PostBack, refreshing the page will have a very bad user experience.

2) unfriendly search engines.

3) be especially careful when writing server code, especially when determining ispostback.

Although PostBack plays an important role in the WebForm event mechanism, it greatly facilitates the event-driven development of WEB applications. It does have an important significance in the short-term entry application. However, starting from the reality, we still have to make preference based on different application scenarios. In front-end applications of the website, we should eliminate all kinds of PostBack that can be eliminated. As a front-end, it is used to display and query data. If you use PostBack for queries, paging, and other operations, on the one hand, the search engine is unfriendly, on the other hand, it brings a very bad user experience to most users, and increases the request time of the entire page. At the same time, the parameters they are transmitted are very limited. In this case, you need to use the Link Method to transmit the parameters.

For application-oriented background development, there may be a large amount of form data when submitting data. At this time, combined with DetailView or FormView, using PostBack to submit data can bring us great convenience. In this case, we do not disable ViewState, and ViewState is not very large, as for the refresh issue, we can use UpdatePanel to help solve the problem. However, if you still need to pay special attention to browsing data, especially when querying the PostBack data on a page with a GridView, you should try to change the page to a link.

In general, you should pay special attention to the use of PostBack, but sometimes it will bring us great convenience. If EXT is used for application-oriented background development, You can discard WebForm or MVC. Because it has its own complete development process, it is indeed a brand new experience.

The PostBack and ViewState discussed in two consecutive articles may all be negative. Their existence is significant, but it will inevitably bring some negative effects. However, the price of this impact is often too high, leading to the opposite reaction of most people. In software engineering, the software measurement standard is not as fast as possible, but to get the correct results within a reasonable time range accepted by the user, and the cost (including development, maintenance, deployment, and other costs) are the least. I believe that they can play their full role as long as they are used properly.

In extreme cases, WebForm is still WebForm after PostBack and ViewState are removed. It is just a double-edged sword with two distinct advantages and disadvantages. The remaining event mechanism, componentized development, and page model are still the most powerful weapon for WebForm development.