In 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.
Using Visual Studio 2005 DataSet Designer to Build a Data Access Layer
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.
Data Access Layer: Typed Data Sets
In short, typed data sets can be described as classes derived from DataTable and created using Visual Studio Designer. ADO.NET DataSet, as well as the DataRow classes. They expose type safe API for accessing data that is contained within a DataSet that might have a particular schema. Typed data sets are created in Visual Studio via a few simple drag and drop operations, as well by setting up properties in the designer’s Properties window.
What one actually succeeds in creating through the design of a typed data set is an XML Schema Definition file that contains the schema of the data that will subsequently be contained by the DataSet. The XSD file will also contain annotations that associate it with the data source it had been generated from. Thus, Visual Studio utilizes the created XSD in order to generate a code file that will contain the typed data set class definitions.
When data is worked with in an application, that data usually gets partitioned off in to various logical business entity types, like Suppliers, Products, Customers etc. In order to work with that information, you will have to encapsulate those logical entities in the form of objects that you are able to work with in your code.
It is possible to write a custom class for each type of entity. Such entity types would then expose properties for each of the data values included by the entity. Then, you will want to create a custom collection type for each entity type to enable strongly typed collections to contain such entities.
Typed data sets are a great alternative to having to create a bunch of custom types on one’s own. Basically, when a typed data set has been created, a set of custom type definitions has been forged as a means of containing logical business entities as well as collections of such entities – a similar process to the writing of such types by hand.
The difference is that when the designer has done it in such a declarative way, then it is a lot easier to visualize, edit, and keep the data synchronized with the database schema that populates the business entities in question. Visual Studio code generation takes care of writing all the underlying properties and methods that provide one with a strongly typed API for dealing with business entities in one’s consuming code.
Moreover, as those have been inherited from ADO.NET types, then the rich relational data manipulation functionality that is inherent in such types has also been inherited. Such types also tend to align themselves well with the data binding capabilities of ASP.NET and Windows Forms, so if you find yourself setting up data binding utilizing the objects, then you will have a lot less work to do on that front also.
Lastly, when a typedate data set has been created in Visual Studio 2005 from a database, a table adapter type is also created for each table that has been added to the data set. A table adapter can be thought of as a fully fledged data access component that allows one to update and retrieve data from a database. It consists of a connection, a data adapter, and a set of command objects that allow one to execute queries to a database.
DataSets and Business Objects
In addition to deciding which .NET language you want to employ, you should also choose whether or not you wish to employ DataSets. Typed data sets can be rather easy to generate via the designer. They also provide a safe AFI for the containment of business entity info. What is more, they already come ready to support such advanced features as sorting, change tracking, filtering, and searching.
Much of the resistance to DataSets has arisen from performance shortcomings inherent in the .NET 1.1 implementations. Top among these shortcomings were a poor performance record when working with bigger DataSets, as well as the fact that DataSets tend to serialize themselves as XML. This has bandwidth and performance implications when passing DataSets across remote boundaries.
Such problems were subsequently fixed in .NET 2.0. There has been a vast quantity of other improvements, so if you have not taken a look at DataSets since 1.1, then you should do yourself a favor and take another look.
One alternative to the utilization of DataSets is the creation of custom object types that are representative of each of your business entities, then using custom collection types as containers for those. But by going in this direction, you wind up having to write a vast majority of the code on your own.
In Visual Studio 2005 and .NET 2.0, this process has become a lot easier than it was before, thanks to such additions as code snippets and generic collection classes. But in order to support the complete range of features provided by a DataSet, one needs to write a fair amount of custom code by hand.
Custom objects are advantageous in that they give you complete, explicit control over the way a type is designed, what the API is, and what its internal capabilities may be. If you are the type that prefers a more object oriented design method, then using customized business entities might be the better route to go.
You can accomplish the same amount of goals with a typed data set as you can with a custom business entity. The only difference is that there may be some things that are less clean with a typed data set if it happens that the things you are attempting to do do not map well to the relational nature of a typed data set.
But if you are mainly getting business data for the purpose of then presenting that info, allowing a user to work with it, and plan on persisting the data back to the database, then you will be able to get things done a lot faster with typed data sets if you harness the DataSet designer features.
