Tutorials Application DevelopmentIn 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.
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.
First Page: N-Tier Architecture: Data Access Layer
