Overview
Component-based frameworks, such as ASP.NET, encourage the design-time configuration of components that you place on individual Web pages. While there are undeniable benefits to the component-based approach, some areas of development, particularly those associated with data access, may be better served by a different solution.
In this article I describe an object-based alternative to the design-time use of data access components. This technique involves building reusable data objects that can be used by many different pages of your ASP.NET application, as well as across different ASP.NET applications.
I’ll begin with an overview of component-based development and how it normally improves productivity. But these benefits are limited in the realm of data access components, as you will learn. I’ll then turn to the main focus of this article: how to build reusable data access components using an ADO.NET data provider.
While this example could have been created using any available ADO.NET data provider, the SQL Server data provider, found in the System.Data.SqlClient namespace, is used here. Similarly, this demonstration could have been created using any .NET version or development tool (though there would be some slight differences in the Web config entries, depending on the .NET version). CodeGear’s RAD Studio 2007, which employs the .NET 2.0 framework, is used in this example.
Component-Based Development
ASP.NET is a component-based framework for building dynamic applications for the World Wide Web. A significant feature of components is that you can configure them at design time. Once a component is placed on its design surface, its properties can be set using the Properties Windows (Visual Studio) or the Object Inspector (Delphi).
Properties set at design time influence how your components appear and behave at runtime. Furthermore, since the use of properties reduces the overall amount of code that you have to write, there is less code for you to debug and maintain.
While the designer generates some code to support the property values that you set at design time, the designer, and not you, maintains this code. This is particularly true about ASP.NET 2.0, where the bulk of this designer-based code is inserted directly into the aspx file.
The two most popular integrated development environments (IDEs) for building ASP.NET applications, Visual Studio for .NET and CodeGear’s RAD Studio, are component-based environments. Designers, component editors, and other support tools within these environments encourage the component-based, that is, design-time approach to application development.
ADO.NET data providers are also components. Particularly in ASP.NET 1.1, you can place these components onto your Web pages and configure them at design time by setting their properties. While the approach is somewhat different in ASP.NET 2.0, where you use a SqlDataSource to access your data, the design time use of the SqlDataSource is convenient, thereby subtly (or maybe not so subtly) encouraging its use.
Placing your data access components onto your web pages produces little in the way of reusable code
But there is a drawback to the design-time use of ADO.NET components. Placing your data access components onto your web pages produces little in the way of reusable code. Specifically, whether you are using ADO.NET 1.1 components such as IDbConnections, IDbCommands, and IDataAdapters, or ADO.NET 2.0 SqlDataSources, these components are placed and configured on a page-by-page basis. The diagram shown in figure 1 represents this approach.
Fig. 1: Design-time components are placed and configured on a page-by-page basis
Specifically, the design-time configurations you set on one page are, for the most part, independent of those defined on another page (in many cases, only the connection string is shared between pages, and sometimes not even that is true). Consequently, if you need to make subsequent changes to your data access, these changes must be applied separately to each page that is affected.
Another way to describe this is that there is little in the way of code reuse when most of the configuration of your components occurs at design time.
Data Layers and Code Reuse
There is another approach that provides a great deal of code reuse, and this involves the implementation of a separate class that handles the details of data access. This object is sometimes referred to as a data layer, though other terms, such as “data abstraction” or “business object” are sometimes used. In order to simplify the discussion that follows, I’ll talk as though the data layer is implemented in a single class, or object. In practice, however, your data layer may actually be implemented as a group of two or more classes that work together to provide your Web pages with data.
Unlike components, the data layer does not reside on the page. Instead, individual pages that need the features provided by the data layer refer to it. Furthermore, more than one page can refer to the data layer, even pages that are part of entirely different web applications. The diagram in figure 2 roughly represents the relationship between web pages and the data layer.
Fig. 2: Two or more pages can use the features exposed by a data layer
One of the more significant characteristics of the data layer is that it is independent of the pages that use it. In other words, the data layer provides data access services to pages that request them, but the data layer is entirely unaware of any characteristics of the pages themselves. In other words, the data layer and the web pages that use it are loosely coupled.
One of the more significant characteristics of the data layer is that it is independent of the pages that use it
Because a single data layer class can be used by many different web pages, changes to how you access your data can sometimes be implemented simply by modifying the data layer itself without having to even touch any of your individual Web pages. Once these changes have been put in place, every page that uses the data layer benefits immediately.
While data layers provide a number of attractive capabilities, you may be wondering why this approach to data access in the .NET framework is not discussed more often. For example, when a Microsoft representative is demonstrating the capabilities of ASP.NET and Visual Studio, you will nearly always see the presenter placing and configuring components at design time. Not once have I observed such a presentation where a data layer is employed.
The answer to this question is that components are easy to use. They are easy to place, and they are easy to configure. Data layers, on the other hand, take advanced preparation. In addition to designing the pages of a web site, you must also design your data layer, and this step requires that you give consideration to the needs of your web site.
One of my colleagues explained this nicely. “Components,” he said, “demo well.” In other words, the use of components makes building database applications in ASP.NET look easy.
“Components,” he said, “demo well”
But here is the problem. Design time placed data access components do not necessarily scale well. While they may work fine for a small application, for larger projects you are almost always better served by reusable classes that centralize core functionality. In general, the benefits of using a data layer increase in proportion to the size and complexity of your ASP.NET application.
Building A Data Layer
You build a data layer by creating one or more classes that take responsibility for data access. At a minimum, the data layer must have access to a database (or some similar data store). This access is typically managed by the data layer directly, although in some architectures, a separate class within the data layer is responsible for managing the data connection.
In addition, a data layer must permit its consumers to make requests of the database. In nearly every situation, this involves requesting data. This data can take the form of scalar (single) values returned from a database (such as the number of records in a given table), a navigable cursor to data (like that returned by an IDataReader), or a result set in the form of a DataTable or DataSet.
A data layer might also permit its consumers to make data manipulation requests. For example, a data layer may expose methods that its consumers can use to delete one or more records, to create new tables or indexes, or to modify existing table structures.
In most cases, a data layer limits what consumers can do, encapsulating and controlling elements such as connections
In the most extreme case, a data layer may provide its consumers with direct access to the connection or connections that it manages, permitting those consumers to perform almost any task imaginable. In most cases though, a data layer limits what consumers can do, encapsulating and controlling elements such as connections.
The data layer described in this paper is a very generic one. It is so generic, in fact, that it might be possible to use it from almost any ASP.NET web page without modification to provide for the most common types of data access.
Let’s consider the structure of this data layer without further delay. The listing below shows the structure of this data layer using the Delphi language. I selected Delphi for this purpose because, unlike the C# language, Delphi classes are declared in a coherent type declaration, which makes their structure easy to see. However, the language of implementation is a detail, and a similar class could be defined using any object-oriented, first class .NET language
type
TSqlDataModule = class(TObject, IDisposable)
Private
FConnection: SqlConnection;
FApplication: HttpApplication;
FRequest: HttpRequest;
FResponse: HttpResponse;
FSession: HttpSessionState;
FTrace: TraceContext;
public
constructor Create(Context: HttpContext;
Trace: TraceContext);
procedure VerifyLogin;
procedure Dispose;
function ExecuteNonQuery(Stmt: String): Integer;
function ExecuteScalar(Stmt: String): TObject;
function ExecuteDataReader(Stmt: String):
SqlDataReader;
function ExecuteDataTable(Stmt: String): DataTable;
//The following is a typical domain-related method
function GetCustomerReader(CustID: String):
DbDataReader;
//Please see comment associated with GetConnection
//method for warnings about using this method
function GetConnection: SqlConnection;
procedure ReleaseConnection;
property Application: HttpApplication read
FApplication;
property Request: HttpRequest read FRequest;
property Response: HttpResponse read FResponse;
property Session: HttpSessionState read FSession;
property Trace: TraceContext read FTrace;
end;
To begin with, this data layer, named TSqlDataModule, is a descendant of TObject (which is equivalent to Object in the .NET framework), and implements the IDisposable interface. That this class descends from TObject simply means that there is very little that it inherits, other than basic behaviors such as ToString().
As I mentioned earlier, most data layers need to manage their connection, which typically includes closing the connection when the data layer’s consumers are through using it, due to the high availability requirements of the ASP.NET environment. For this reason, this data layer implements the IDisposable interface, which requires the data layer to expose a Dispose method. When a class implements IDisposable, it is a sign to developers using that class that they need to call Dispose when they are through using the class, so that the class can release resources that it used. For the data layer, this means closing its connection.
The following is the Dispose method of the TSqlDataModule class.
procedure TSqlDataModule.Dispose;
begin
FConnection.Close;
FConnection := nil;
end;
The constructor of this data layer is especially noteworthy. It takes two parameters. These parameters are objects that are available to every web page in an ASP.NET application. By passing these parameters to the data layer, you enable the data layer to perform tasks that would otherwise be limited to the page itself.
For example, because the HttpResponse object is available through the HttpContext that is passed in the first parameter to the data layer’s constructor, the data layer can issue HttpResponse.Redirect commands, as well as read from query string (HttpRequest.QueryString) and form field values (HttpRequest.Form). Likewise, the TraceContext object passed in the second parameter permits the data layer to write to the debug trace, improving your ability to monitor what is going on inside the data layer.
As far as exposing data access capabilities, this data layer is particularly flexible. In all, this data layer exposes five different methods that a consumer can use to access data. ExecuteNonQuery permits a consumer to execute a query that does not return a result set (only an integer indicating the number of records that were affected). ExecuteScalar returns a single value from a query result set. ExecuteDataReader returns a readonly, forward-navigating cursor. ExecuteDataTable returns a DataTable containing query results. Unlike the three previous methods, ExecuteDataTable is not a method of the IDbCommand interface, but performs the same task as an IDbDataAdapter when it fills a DataTable with data.
The fifth method is GetCustomerReader, which is most representative of the methods that a data layer might expose. While the first four methods are tremendously flexible, most data layers expose a large number of methods that are specific to the database domain. GetCustomerReader, for example, takes a value that represents the key of the customer table, and returns a SqlDataReader that contains the associated customer’s record.
The code in sourcefile "uSQLFunc.pas" contains the implementation of these five methods.
on e: Exception do
begin
Trace.Warn('SqlDataModule:
ExecuteNonQuery error, ' + e.Message);
end;
As you can see from this listing, the TraceContext object that was passed in the data layer’s constructor is used in these methods. If an error occurs within one of these methods, a warning is written to the debug trace. Writing errors to the trace greatly simplifies the process of locating errors in your ASP.NET applications, especially if the errors indicate within which method the error was raised, as they do here.
There are two more features of this data layer that are notable before we turn our attention to using the data layer. The first is the set of five properties exposed by the data layer. Specifically, the five ASP objects (HttpApplicationState, HttpRequest, HttpResponse, HttpSessionState, and TraceContext) are exposed as public properties. This permits these useful objects to be used by any classes that this data layer gets passed to.
For example, your web page code may pass the data layer to an object that has intimate knowledge of your underlying database tables, and which can validate data that needs to be written to your database. If that object needs to write to the TraceContext, or read from a session variable (or any other task available through these ASP objects), these properties provide that access (The TCustomerOrders class defined in this example is used to create such an object).
Finally, this data layer exposes a public method named VerifyLogin. This method can be called by any web page that uses the data layer to verify that the person attempting to view the page has logged in. If the user has not logged in, VerifyLogin redirects the user to the login page.
For this example, the VerifyLogin method is extremely simple. It merely ensures that the user has previously provided a valid user id (which is written to a session variable called username when the user successfully logs in). If the username variable is not found, the HttpResponse object is used to redirect the user to the login page. This can be seen in the following implementation of VerifyLogin.
procedure TSqlDataModule.VerifyLogin;
var
s: String;
begin
if FSession['username'] = nil then
Response.Redirect('login.aspx');
end;
Remember, most web pages that need to limit access only to authorized users should use a more thorough user validation than that provided by this trivial application. I included VerifyLogin to keep this example simple while demonstrating the spirit of validation.
Using the SqlDataModule
You use a data layer by calling its constructor from any web page that needs its services. Once you have called its constructor, you can then call one of more of its methods. When you are through using the data layer, simply call Dispose before the web page goes out of scope. (This is a very important point if your web site gets much traffic at all.)
To appreciate when you should create your data layer, you need to understand the ASP.NET web page life-cycle. A complete discussion of the web page life-cycle is beyond the scope of this article, so let me simply discuss three specific pages of the web application that demonstrate the creation of the data layer at different points in the life of a page. In particular, I want to focus on Homepage.aspx, Login.aspx, and DataForm.aspx, three of the five pages in this application. The home page of the application is shown in figure 3.
Fig. 3: The home page of the sample application
The page shown in figure 3 is a static page. Specifically, it always appears the same each time it is created. Furthermore, since it requires no database connection, this page does not create a SqlDataModule.
If you are already logged into this application, you can click the “Click Here” link following the phrase “Already Logged In” from the home page. Doing so directs you to the page named DataForm.aspx. However, DataForm.aspx calls the data layer’s VerifyLogin method, which will redirect you to the Login page if you have not already logged in. The Login page is shown in figure 4.
Fig. 4: The Login.aspx page of the example application
The sourcecode of this unit can be found in "uLogin.pas".
The needs of the Login page are special. Specifically, the Login page does not require any services of the data layer until the user attempts to log in. Indeed, when the page is first rendered, an instance of the data layer is not even created. It is only after the user clicks the Login button (and its LoginButton_Click event handler fires) that the data layer is even created.
As you can see from the LoginButton_Click event handler, an instance of the data layer class is created (with the two ASP objects being passed to it) when a user attempts to log in. If ExecuteScalar does not return the value 1, the user id was invalid, an error message is set, and the login page simply re-renders (with the error message displayed).
On the other hand, if the user enters a valid user id (ExecuteScalar returns 1), the HttpResponse object is used to redirect the user to the DataForm.aspx page. DataForm.aspx is shown in figure 5.
Fig. 5: The DataForm.aspx page of the example application
Note that whether or not the user logs in successfully, the finally clause in the LoginButton_Click event handler ensures that the data layer object is disposed. When disposed, the data layer closes its SqlConnection, which permits this connection to be immediately returned to the connection pool (most .NET data providers support connection pooling). If you fail to call Dispose, the connection will not be returned to the connection pool until the .NET garbage collector gets around to destroying the data layer, which may not happen for a while.
In this case, the data layer is created and disposed within a single event handler. For every other page in the example application (with the exception of the Home page, which needs no connection or login verification, and therefore does not employ a data layer instance), the data layer is created on each and every rendering of the page.
This can best be seen in the code associated with the DataForm.aspx Web page. This code can be found in the sourcecode file "uDataForm.pas".
Because this page needs to verify any users who request it, the data layer object is created in the OnInit event handler for the page. Not only is the data layer created, but its VerifyLogin method is called, which as described previously, will redirect the user to the Login.aspx page if they have not already logged in at least once during their browser session.
Just as with the Login page, it is essential that the data layer be disposed when it is no longer needed. On this page, and all others in this application where the data layer is created in the Init event, the data layer is disposed in the page’s Unload event handler. This event handler executes at the end of the page’s life-cycle (even if a Redirect call has been issued sometime earlier in the page’s life).
Notice also that the variable SqlDataModule is declared visible to the entire page class. As a result, once it has been created, it is available to any of the remaining methods that may get called during the page life-cycle. For example, when the page has been loaded for the first time (the page’s IsPostBack property is false), the data layer is used to return a data reader listing the customer’s whose records appear in the customer table.
These few examples should give you a good idea of how the data layer is being used. I encourage you to view the source code for the sample application for examples of other method calls exposed by the data layer class. You can download this code from the SDN-site or via http://www.JensenDataSystems.com/code/datalayer.zip
Summary
While Microsoft’s Visual Studio and CodeGear’s Delphi both permit you to build your applications using a component-based, design-time approach, you should at least consider alternative methods, particularly when it comes to data access. The data layer example demonstrated in this paper is one such alternative, one that provides many advantages over the design-time approach.
Although the data layers demonstrated here were quite flexible, they represent only a small part of what you can do using this architecture
And although the data layers demonstrated here were quite flexible, they represent only a small part of what you can do using this architecture. Specifically, you can create data layers that have intimate knowledge of your data domains. Not only can these data layers be designed to access your data, but they can implement business logic as well, validating data and taking responsibility for writing that data to the underlying tables in the correct format. From this perspective, the data layer examples presented here are trivial, demonstrating only a small part of the potential power of this approach.
At the same time, I would be negligent if I did not acknowledge that the design-time approach has some significant advantages. The designers, component editors, and helper classes that are available at design time offer significant assistance in configuring data access components. Especially when your applications are simple, the extra time and effort that it takes to design a data layer may not be warranted.
Even if you do decide to design a data layer, you can still take advantage of this assistance provided during the design-time configuration of data access components. For example, while the connection strings used for the data layer classes in these example were defined in the web.config files (and were loaded by the data layer classes in their constructors), you might want to use the design-time helpers to create your connection strings, which you can then copy from the design-time generated source files (or in the case of ASP.NET 2.0, from your associated asp tags in your aspx files), and use them in your data layer classes.
I also want to acknowledge that there are some aspects of ASP.NET development that are somewhat more complicated when you take the data layer approach. Specifically, in most cases, when using a data layer, you must define all data bindings at runtime. (See the Load event in one of the listings for an example of this data binding). On the other hand, in ASP.NET 2.0, you can use the ObjectDataSource, which if you design your data layer appropriately, can be used to bind controls to your data layer at design time.
These points aside, the use of data layers provide you with a powerful, reusable mechanism for managing your data access needs in ASP.NET applications.
Sources
De sources die bij dit artikel horen kun je downloaden via Jensen_ReusableDataLayer4AspNetApps_SRC.zip.