Building a User Interface Quickly Using Data Binding

Brief Introduction to Web Applications

This chapter will serve as an introduction to Web applications. Many books are dedicated to the ASP.NET technology, including some specifically geared toward ASP.NET data access programming, such as Building Web Solutions with ASP.NET and ADO.NET by Dino Esposito (Microsoft Press, 2002). This chapter will provide some basic background to building Web applications that use ADO.NET to communicate with your database. Along the way we'll learn a little about data binding, the pros and cons of various ASP.NET caching options, paging, and submitting updates. Most of the examples will focus on the most powerful and flexible of the ASP.NET data bound controls: the DataGrid.

ASP.NET Makes Building Web Applications Easier

In order to build a Web application, you write code that runs in a Web server that generates HTML that the browser will translate into a Web page. You also need to include functionality in the Web page that allows the user to click buttons or links to post data back to the server. Finally, you need to write code to allow your Web server to respond to those post-back events and interpret the information that the user posted.

ASP.NET greatly simplifies the process of building Web applications. You can write ASP.NET code in your language of choice—Visual Basic .NET or Visual C# .NET. Simply set properties on ASP.NET Web controls like you would with standard Windows controls, and the controls automatically translate those settings into HTML. If you place an ASP.NET Button on your Web Form and add code to the Button control's Click event, ASP.NET will automatically add HTML to the corresponding Web page so that the Web server will run the code for the Click event when the user clicks the button. Thanks to the metadata that ASP.NET adds to the page, your code can access settings on your controls to collect the information that the user posted.

Many developers who have built ASP.NET applications aren't aware of the ASP.NET features that make building Web applications so simple. That's part of the power of ASP.NET. For example, some developers might not truly understand that the ASP.NET code and the HTML user interface are running on separate machines. Many more developers are not aware that most ASP.NET applications use a stateless middle tier; some might not even know what a stateless middle tier is.

The Good and Bad of Statelessness

When a user directs his or her browser to an ASP.NET page (*.aspx), IIS hands off the request to ASP.NET, which loads the compiled library for that page if it's not already in memory. Once ASP.NET responds to the request, it releases the resources for the page. When the user posts information back to that page, ASP.NET re-creates the page and responds to the post-back event. By default, ASP.NET does not maintain any information about the user's session between requests.

This statelessness makes your ASP.NET applications more scalable, but it can also prove challenging to developers who might not have experience building applications that rely on a stateless middle tier.

Forgetful Server, Dumb Client

In some ways, Web applications are similar to traditional mainframe applications. The Web server performs the majority of the actual processing. The Web browser might offer helpful features such as allowing you to bookmark sites, but its primary job is to transform the data that the Web server returns into a simple user interface.

For example, say you write ASP.NET code that uses a DataAdapter to fetch product information from your database into a DataTable. You then bind a Web DataGrid to the DataTable to display the product information on your Web page. Let's also assume that you've added a button or a link for each product to the Web page so that the user can add that particular product to a shopping cart.

ASP.NET helped you convert the results of the query into HTML that the Web browser then displayed. But once ASP.NET finished responding to the page request it released the page's resources, including the DataTable of product information. The Web browser displays a visual representation of the results, but it didn't actually receive the DataTable object. In fact, even if the browser did receive the DataTable object, it wouldn't know what to do with it; it's not .NET aware, so to speak.



Microsoft ADO. NET Core Reference
Microsoft ADO.NET (Core Reference) (PRO-Developer)
ISBN: 0735614237
EAN: 2147483647
Year: 2002
Pages: 104
Authors: David Sceppa

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net