Server Controls

The ASP.NET page revolves around server controls that encapsulate user interactions, data, and even business logic. The event-driven architecture of the server controls presents a familiar environment for developers. The automatic management of state allows you to focus on the application instead of overcoming the stateless nature of the HTTP protocol.

• A certain amount of overhead is associated with all server controls. To preserve application performance when leveraging existing HTML content, do not turn HTML elements into HTML server controls unless you are taking advantage of server events.

• Remember that updating a user control will cause the compiled pages that reference the user control to become invalidated. When the pages are next requested, they will have to be recompiled.

• The members of a user control in the output cache can’t be accessed from pages that contain the control. The output of the cached control will be included in the page, but the user control object itself will not available. Attempting to access it will result in an error message.

• If you have to import the System.Windows.Forms namespace into your page or Microsoft Visual Studio .NET Web application project, chances are your code is using server-side resources that have no visible desktop on which to be displayed. Thus, they must be disposed of to avoid introducing resource issues under heavy load.

• When the user interface supports multiple simultaneous selections while iterating the list of items, accessing SelectedItem, SelectedIndex, and SelectedValue will return the first item found. To get the complete set of selected items, loop through all items from the list.

• Items added to a list control are carried between client and server in ViewState. If the set of items is a significant size, consider disabling ViewState. That way the control will not bloat the payload by unnecessarily carrying the ViewState in a round trip between client and server. In this case, be aware that the selected items are no longer available, so you must provide code to ascertain when the selected items were changed.

• To create a drop-down list that does not have an initially selected value, add an item to the top of the list that is selected by default and corresponds to no selection.

• Disable client-side validation by using the Page directive’s ClientTarget attribute. Setting this directive to downlevel causes ASP.NET to treat the browser as though it does not support JScript.

• When used with sophisticated clients, client-side validation can reduce server load and improve the customer experience by providing immediate feedback about a problem without issuing a request to the server.

• Always verify the data received by the server, even when client-side validation code has been provided. You can’t safely assume anything—the client might not have run the code, and the user might have constructed a malicious request with values that would not pass the examination of the client-side code.

• Use the SaveAs method of the PostedFile member of the HtmlInputFile to specify where the file should be placed on disk. Target a directory that exists on a separate partition, where filling the partition will have minimum impact on the operations of the server.

• If you need to generate random numbers in your application, create a Random object and store it in application scope. The object is seeded when it is created and can then be used throughout the application to get differing values easily.

• When deploying in a Web farm without server affinity (meaning that for each request, a client session can be handled by a different server), the validation key must be set explicitly and synchronized between the machines. If the default AutoGenerate setting is used, postbacks handled by a machine other than the one in which the ViewState was generated will not be processed correctly, and the user will get an error.