Not arise if you have the feeling that many of the software development projects in which you participated as a developer, something similar? Namely, for different projects, different programmers admit the same, standard error. Of course, we are not talking about syntax errors. This is a "problematic" code, which initially failed to work properly, but later (during development or, even worse, after commissioning), it becomes the source of the various inconveniences and problems.
Then change the password must recompile the program, then "make such a report for the time that we have left, is absolutely unreal," then web-based application begins to slow down even at twenty users, although they plan to be at least hundreds. Especially hurt when it turns out that allowed the elementary errors that easily could have been avoided. But as pre-guess who from programmers and some "elementary" make a mistake? Each programmer "Controller" not put. Of course, I would like to all elementary errors in the course projects were carried out during training programming. But it did not work.
There is a known practice of testers – maintain a list of error types and ways of their diagnosis. This greatly simplifies the search for bugs in your application. Fighting bugs by testing and subsequent modifications of the product – a required stage of development.
However, you can save a lot of time and effort, you learn to prevent errors. To do this, learn from testers useful practice to maintain a list of typical errors. For each error such list should include a section "how to avoid it?". Keep a list handy, forewarned – that is armed. But there is one problem. Familiarization with the list does not relieve the programmer to life (as opposed to the tester, which uses such a list of good saves time). Why? Yes, because in many cases, to avoid error, we should at least think about it. And often, to insure against future problems, you need to write a non-trivial code, which again must come up with. Most likely, the developers simply will not read everything, just in case. But still try to make the first steps are taken: provide error descriptions in human readable form – in the form of small notes, to provide these notes, one after another, with the accumulation of notes – to introduce a classification of types of errors. To begin with – a useful article about the possibility of ASP.NET, capable, however, destroying blood "programmers.
View State – so in ASP.NET is called the way of storing data on the status page in a hidden form field on the page. When the form is transmitted from client to server, data from the hidden field is used to for a specific client to establish the state of server objects that form the page. View State allows you to save a client state of the web-interface, while not used cookies (which can be disabled on the client) or server memory (which may not be enough work for a large number of users).
View State is used in many server controls ASP.NET (for example, DataGrid), to remember their current status. Example – to save form field values ??on the page during a paging scrolling lists.
However, the application of View State has not only advantages but also disadvantages.
First of all, when you use View State page becomes "harder", both for processing and for transmission to the client, due to the extra volume. Further, the additional stress associated with the formation and collated data of the hidden field View State. And finally, for the treatment View State is still required memory on the server.
Some server controls, in particular, DataGrid, capable of extremely active use View State, even if it is not necessary.
By default, the View State is included. Therein lies the problem. Likely to ASP.NET developers wanted so to draw attention to the programmers of this technological "fiche". In part, they succeeded. But those programmers who "have not noticed" innovations or use it without thinking, able to generate an equal place these monsters. A common scenario is this: the programmer uses ViewState implicitly working with server-side "control", and sometimes explicitly, because the object – handy dictionary to store its own data. "The combined efforts of the" server "control" and the programmer can easily lead to unnecessary swelling, a hidden field containing the data ViewState, so that its volume may exceed the amount of pages a few times. Response time to the user increases, the application becomes "sluggish". Work with such an application via the Internet on weak channels can be simply impossible.
Then there is the natural desire to reduce the size of the page. View State to find box is not difficult, to figure out how to turn it off – too. You can turn off at the level of control, as you can – at the page level:
<%@ Page EnableViewState="false" %>
And here the problems begin. Or start to lose the user’s field values, vanish our internal data that we stored in the dictionary View State, not to tinker with their own hidden variables or cookies. Now you have to "scour" the code form the page to replace the reference to View State on something else, as well as catch the moments when discharged necessary for the user the meaning of "control". In general, the process of development of these alterations is not accelerated and reliability of the code is not increased.
Hence, make a simple conclusion – do not ignore the ViewState. All you need to View State was helpful, not harmful, it is the beginning of work on the page to think about how on this page the best use of this opportunity.
If a page is not designed to retrieve data from the client, or if the controls on it are generated dynamically, you should disable View State for the page level. In other cases, you may need to disable the View State-level controls. Do not store in the dictionary View State volumetric data, and do not use it as the equivalent of the heap for temporary variables. Such actions are likely to lead to problems in the future.