Database Access in the Web World

Accessing a database in a web application is a completely different scenario than accessing a database in a typical client-server desktop application. Most developers hone their database skills in the desktop world and run into serious problems when they try to apply what they have learned with stand-alone applications in the world of the Web. Quite simply, web applications raise two new considerations: problems of scale and problems of state.
Problems of scale are the problems that can result from the massively multiuser nature of the Web. A web application has the potential to be used by hundreds or thousands of simultaneous users. This means it can’t be casual about using server memory or limited resources such as database connections. If you design an application that acquires a database connection and holds it for even a few extra seconds, other users may notice a definite slowdown.  And if you don’t carefully consider database concurrency issues (in other words, what happens when the changes from different users overlap), you can run into significant headaches, such as failed updates and inconsistent data.

Problems of scale can occur when developing traditional client-server desktop applications. The difference is that in most client-server applications they are far less likely to have any negative effect because the typical load (the number of simultaneous users) is dramatically lower. Database practices that might slightly hamper the performance of a client-server application can multiply rapidly and cause significant problems in a web application.

Problems of state are problems that can result from the disconnected nature of the Internet.
As you already know, HTTP is a stateless protocol. When a user requests a page in an
ASP.NET application, the web server processes the code, returns the rendered HTML, and closes the connection immediately. Although users may have the illusion that they are interacting with a continuously running application, they are really just receiving a string of static pages.
Because of the stateless nature of HTTP, web applications need to perform all their work in the space of a single request. The typical approach is to connect to a database, read information, display it, and then close the database connection. This approach runs into difficulties if you want the user to be able to modify the retrieved information. In this scenario, the application requires a certain amount of intelligence in order to be able to identify the original record, build a SQL statement to select it, and update it with the new values.
Fortunately, both ASP.NET and ADO.NET are designed with these challenges in mind. As you work your way through this chapter (and the following two chapters), you’ll learn how to deal with databases safely and efficiently.

Using Access Data on an ASP.NET Web Page

You can now use the database in a Web page. This part of the walkthrough uses an AccessDataSource control and a DataList control.

To add AccessDataSource and DataList controls to the page

1. Open the Default.aspx page (or another page that you want to use) and switch to Design view.
2. From the Data group in the toolbox, drag an AccessDataSource control onto the page.

   Note  If the Access Data Source Tasks menu does not appear, right-click the control and then click Show Smart Tag.

3. On the Access Data Source Tasks shortcut menu, click Configure Data Source. The Configure Data Source wizard is displayed.
4. On the Choose a database page, in the Microsoft Access Data file box, type ~/App_Data/Northwind.mdb or use the Browse button to select the .mdb file.
5. Click Next to open the Configure Select Statement page, and then click Specify columns from a table or view.
6. In the Name list, click Categories.
7. Select the CategoryName and Description check boxes and then click Next.
8. Optionally, click Test Query to test your query.
9. Click Finish.
10. From the Data group in the toolbox, drag a DataList control onto the page.
11. On the DataList Tasks menu, in the Choose Data Source box, click AccessDataSource1.
12. Click Ctrl+F5 to run the page with the default layout.
13. Close the browser.

What is not in the Next Version of the Framework

What is not in the Next Version of the Framework
- The “ADO.NET DataServices” samples are for demonstration purposes and not planned to be added to the framework.

- The “Dynamic Data Futures” samples are demonstrating useful techniques that developers may want in their applications but these are not currently planned to be added to the framework.

- The “DomainDataSource” samples that utilize the .NET RIA Services are not currently in the next release of the framework but will instead ship when the .NET RIA Services ships.

.NET RIA Services
This is new technology that is currently in CTP for that provides a framework for building data driven applications that run in Silverlight. One of the components of this framework is a Domain Service which is a pattern for building a business logic layer. Business logic layers are a thin layer of code that sits on top of a Entity Framework or Linq to SQL data model. This business layer gives the developer a simple place to add access security to methods, custom validation by verify parameters before making a call to the data access layer and providing a simple place to inject logic before or after the call to the data access layer.