Using Strongly Typed DataSet Objects
Strongly typed DataSet objects present database tables and columns as objects and properties. Access is performed by name, not by indexing into a collection. This means you can recognize the difference between strongly typed and untyped DataSet objects in the way you access the fields:
string n1 = myDataSet.Tables["Students"].Rows["StudentName"]; // untyped
string n2 = myDataSet.Students.StudentName; // strongly typed
There are several benefits to using strongly typed DataSet objects:
- The code required to access fields is more readable and compact.
- The Intellisense capability within the Visual Studio .NET code editor can automatically complete lines as you type.
- The compiler can catch strongly typed DataSet type mismatch errors. It is better to detect type errors at compile time than at run time.
When to Use Strongly Typed DataSets
Strongly typed DataSets are useful because they make application development easier and less error-prone. This is especially true for the client side of a multitiered application where the focus is on graphical user interfaces and data validation that require many field access operations.
However, strongly typed DataSets can be cumbersome if the database structure changes, for example when field and table names are modified. In this case, the typed DataSet class has to be regenerated and all dependent classes must be modified.
It is possible to use both strongly typed and untyped approaches in the same application. For example, some developers use strongly typed DataSets on the client side and untyped records on the server. The.Merge method of the strongly typed DataSet can be used to import data from an untyped DataSet.
Generating DataSet Classes
Both the .NET Framework SDK and Visual Studio.NET provide utilities for helping you generate the necessary DataSet subclasses. The .NET Framework SDK involves using a command-line tool and writing code. The Visual Studio .NET method, obviously, relies on the Visual Studio .NET development environment and doesn't require you to open a Command window.
Regardless of how the DataSet class is generated, the new class must also be deployed to all tiers that reference that typed DataSet. (This is not a typical scenario, but it is important to consider if passing a typed DataSet across tiers by using remoting.)