Making Data Access Design Decisions


ADO.NET introduces new possibilities for data access programming, which complicates the design process for developers. At the risk of oversimplifying the issue, three main factors influence design decisions:

  • The application architecture

  • The format in which the consumer expects to receive data

  • The format in which the consumer expects to communicate data updates

For the purposes of this discussion, ASP.NET enables two main kinds of applications:

  • N- tier Web applications: Each logical process is separated in discreet classes, such as business components, data components, and frontend components .

  • Web services: These are distributed components that send and receive data using XML.

We will ignore the obvious variations that each application type can provide and distill the issue down to one simple difference: Data is exchanged as XML, or it is not. Furthermore, some applications and components simply retrieve data, and others also allow updates to data.

Data Access Design for N-Tier Web Applications

N-tier applications separate application logic into distinct components, which includes separating data access logic into separate classes. N-tier application architecture has become a standard design because it applies equally well to small, medium, or large applications. Partitioned logic is not only easier to build and maintain, but it enables components to be flexibly distributed across physical servers as the application load increases .

N-tier Web applications follow a typical design:

  1. Write the frontend user interface using Web forms.

  2. Write the business rule components as separate classes that can be called from the code-behind file in the Web forms.

  3. Create a dedicated data access component in a separate class module. This component ideally provides a set of generic functions that encapsulate the ADO.NET object calls. In addition, you may choose to write dedicated functions that are tied to specific database entities in your backend database.

  4. Use typed DataSets where possible because they provide the functionality of the DataSet class along with the convenience of strong-typing for the DataTable fields. There is a performance penalty with typed DataSets compared to standard DataSets; however, you may find this a small price to pay compared with the benefits of coding with strongly typed accessors. The performance penalty will likely increase in relation to the complexity of the underlying XSD schema. However, the exact performance price can only be determined by testing your specific Web application.

The advantages of n-tier application design for data access are as follows :

  • Data access routines are centralized. Changes to any data access routine only need to be made in one component. Code becomes much easier to maintain.

  • There is less repeated code in the application, which makes it easier to maintain and reduces the size of the compiled executable. This indirectly improves the responsiveness of the application because the ASP.NET worker process has a smaller binary file with which to work.

  • Separate components can be located on different physical machines if required. This can improve the responsiveness of the overall application.

The disadvantages of n-tier application design for data access are as follows:

  • Development time is increased in the short term because you need to create several components. (You can minimize this development time by designing your data access components for flexible reuse so that they may be used in another Web application with little or no recoding.)

  • Centralized data access classes can be difficult to write in such a way that they handle all data access scenarios for your application. For example, let's say you do not incorporate output parameters into your wrapper classes. Then, once the application is deployed, a data access requirement arises that can only be handled by a stored procedure that returns an output parameter. You may need to modify the data access wrapper functions to accommodate output parameters, which could impact existing calls. The moral of the story is to think ahead and anticipate as many of your data access needs as possible.

The sample application that accompanies this chapter provides an example of a data access class. It is a huge convenience to be able to call single methods that will assemble the parameter string and instance the required ADO.NET objects for you. In addition, it is more convenient to be able to update global changes to your data access code in one location as opposed to several. We faced this situation recently when we moved a Web application into a production environment and immediately encountered query timeout errors across the application. It turned out that the CommandTimeout parameter was not set high enough for the production environment, even though it had been set perfectly for the development environment. The application's data access component was already using a single private global value for this parameter, so it was a quick operation to update the value and recompile the class. (Of course, you could also store the CommandTimeout parameter in the Web.config file so that you can modify its value without recompiling the data access component.)

Data Access Design for Web Services

Web services exchange data as XML, and as you have seen, the .NET Framework provides a huge amount of functionality for working with XML. The DataSet class will handle most data access scenarios ”from simple data retrievals to complex data updates. The DataSet class will serialize to XML and XSD files in a way that preserves the relational structures in the data. For updates, the DataSet works with the DiffGram schema format, which tracks before and after values as well as errors that arise due to updates. Whatever data access operation you need to perform, there is a good chance you can accomplish it using ADO.NET and XML.

Web services follow a typical set of design principles when it comes to data access:

  • Data requests and responses are exchanged as XML inside a Simple Object Access Protocol (SOAP) envelope. The consumer application must have the ability to format SOAP requests . Optionally, the consumer should be able to work with XML documents, especially if it calls Web service methods that generate schema-specific XML documents.

  • Web service methods return targeted information. They should return all of the information for a specific kind of request. You should never have to invoke two or more Web service methods for the same related request.

  • Web services use targeted methods for updating data. Unless you need to support complex XML structures such as the DiffGram, the best approach for updating data with a Web method is to use a targeted method that calls a specific update stored procedure. Web services can easily throw back exceptions, so the consumer can always stay informed about errors during updates.

  • Web service methods use the most efficient return data type. For example, scalar values should be returned as integers, strings, or another appropriate data type, rather than as a serialized DataSet. In addition, arrays of data may be more efficient than returning a serialized DataSet. For example, we typically use DataReader objects within the Web service method and map the resultset to an array of strings that holds the name -value pairs. This approach enables the Web method to use an efficient object for data access and to return data with an efficient footprint.

The advantages of Web services for data access are as follows:

  • Web service methods will work with a wide range of common data types, as well as custom data types, as long as they are tied to an XML schema file.

  • Web service methods for accessing data provide the same level of functionality as standard data access methods, but with the added benefit that they are not tied to a particular consumer. A Web service component meets all the needs for servicing a local consumer and can also service outside consumers should the need arise. Local and remote consumers alike can use data access code that is written into Web service components.

  • Web service methods can return XML documents, which gives the consumer application flexibility in processing the resultset.

The disadvantages of Web services for data access are as follows:

  • Complex data structures and complex updates typically must involve the DataSet object, which has the highest resource footprint of the available data access objects. Web service methods that exchange and work with DataSets will not perform as well as methods that work with simple data types. They require more resources to work with, and to serialize, and they generate larger XML documents. Recall also that Web services automatically generate DataSets in the DiffGram format, which creates multiple XML records per record of actual data.

  • Web services carry additional overhead compared to local components because they require SOAP and typically require a proxy class. If you are certain you will never to need to invoke data remotely, then you should avoid Web services in favor of using components that can be installed locally to your ASP.NET application.

  • Web services only support stateless, single method calls.

In our recent applications we have moved a fair amount of data access code to Web services. This is mainly because the applications make liberal use of realtime validation, which uses Web services that are hooked into client-side scripts. So, for example, as the user fills in a form field, the application will perform a real-time check against the database for duplicates and other potential validation problems. At the same time, we often need to call these same methods from the server-side code-behind file. We can do this easily by setting Web references between the client ASP.NET application and the Web services. This allows us to invoke the Web services in the same way as we would invoke a regular component. In theory we are taking a performance hit by calling a Web service method from code-behind file instead of calling a standard component. In reality, we have found the performance to be fast enough and certainly acceptable for our particular ASP.NET applications. Ultimately, you need to decide the approach that works best for you.

Decision Flow Diagram

Data access design decisions are complicated and are largely dictated by the application architecture and by the format in which data must be exchanged (that is, XML vs. non-XML). Figure 3-3 presents a decision flow diagram that attempts to capture a broad range of data access scenarios. The diagram suggests primary and alternate data access methods based on a particular data access scenario. The diagram does not encompass all factors, but at the least it will help you start thinking about the best approach for your particular data access scenario.

click to expand
Figure 3-3: Decision flow diagram for data access
Note

For more information on data access design using ADO.NET, refer to the MSDN article ".NET Data Access Architecture Guide" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp .




Performance Tuning and Optimizing ASP. NET Applications
Performance Tuning and Optimizing ASP.NET Applications
ISBN: 1590590724
EAN: 2147483647
Year: 2005
Pages: 91

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