Tutorials Application DevelopmentIn an N-Tier architecture, the data access layer consists of components that aid one in the process of accessing the database. When it is used correctly, the data access layer serves as an abstract level for the structures of the database. Simple changes that are made to the database and to tables and other components will not effect the rest of the application – the data access layer will not allow this to happen! The various layers of the application send their data requests to this layer, and this layer responds.
Only the data access layer may access the database. As a result, this is where field names and table names are hard coded – they are not hard coded anywhere else in the system. The data access layer is also able to access many services that it can then provide with data – these might include Services and Active Directory.
Importantly, the data access layer serves as an extra layer for database security. This is because the other layers do not know database credentials, connect strings, or other sensitive information – with the data access layer, there is simply no reason for them to have access to this knowledge!
On the data access layer, you can write generic methods, which will then interface, with your data. For instance, you might want to write a method for the creation and subsequent opening of a Connection object (internal), plus one more for the creation and use of a Command object, as well as a stored procedure with or without a return value…
The possibilities are endless. It can also contain specific methods, like “saveProduct”, so that in the event that the Product object calls on it with the appropriate data, it can then persist it along to the Data Tier. Obviously, the data layer should contain no business rules or data manipulation / transformation logic – that is for other layers. The data access layer just serves as a reusable interface to the database – no more, no less.
The vast majority of business applications will demand a quality data access layer, no matter whether or not that layer is meant to reside on a web server, a client, or a middle tier application server. When attempted by hand, data access tiers often involve a lot of repetitive coding that is prone to numerous errors.
A lot of that can be alleviated via the design of a set of quality helper and base classes as an encapsulation for the repeating patterns, or through the use of a code generation tool. You might still, however, have to write data access methods by hand for the ad hoc queries that may or may not service large parts of your application.
Much of the pain can be alleviated through the use of Visual Studio 2005. A lot of improvements have been made to the Visual Studio 2005 DataSet designer, making the code it generates so beneficial that eliminates coding data assess methods. Before we explore the possibilities of this software, however, let us first introduce the concept of typed data sets.
Next Page: Data Access Layer: Typed Data Sets
