Effective C # Principle 41: Select a dataset instead of a custom data structure

Because of the two principles, the dataset's reputation has been badly screwed up. First, it is inconvenient to use an XML-serialized dataset to interact with other non-. NET code. If the dataset is used in the Web Services API, it is not used with the other. NET Framework, it can be very difficult to interact with the system. Second, it is a very general container. You can cheat by cheating. NET Framework, the wrong DataSet is the type of security. But in modern software system, dataset can solve many common problems. If you understand its advantages and avoid its drawbacks, you can extend this type.

The DataSet class was designed to work offline using some data stored in the relevant database. You already know that it is used to store the DataTable, and the DataTable is a memory table that matches the structure of the database in rows and columns. Perhaps you've seen some examples of datasets that support building relationships within tables. It is even possible that you have seen an example of validating the data contained in a dataset and making data constraints.

But more than that, the dataset also supports AcceptChanges and RejectChanges methods for transaction processing, and they can be used as DiffGrams storage, which includes data that has been modified. Multiple datasets can also be merged into a regular repository. The dataset also supports views, which means that you can detect some of the content in the data through a standard query. and views can be built on multiple tables.

However, some people want to develop their own storage structure without using a dataset. Because the dataset is a very generic container, this can have a loss in performance. A dataset is not a strong type of storage container, but the object stored in it is a dictionary. and the columns in the table are also dictionaries. The elements stored in are all in the form of System.Object references. This allows us to write code like this:

int val = ( int ) MyDataSet.Tables[ "table1" ].
　Rows[ 0 ][ "total" ];

In the C # strong-type view, such a structure is cumbersome. If you use the Table1 or total type incorrectly, you will get a run-time error. Access to the data elements inside to be forced conversion. And this kind of trouble is in direct proportion to the number of elements you visit, so we really want a typed solution. So let's try to write a dataset, and based on this, what we want is:

int val = MyDataSet.table1.Rows[ 0 ].total;

When you see the C # Implementation within the typed DataSet, you'll know it's perfect. It encapsulates a DataSet that already exists, and it adds strongly typed access based on a weak type of access. Your users can still use the weak type API. But it's not the best.

With it at the same time, I will tell you how many things we have given up. I'll tell you how some of the features in the dataset class are implemented, which are used in custom collections that we create ourselves. You might find it difficult, or you think we're using all the features of a different dataset, so the code isn't very long. OK, good, I'll write very long code.

Suppose you want to create a collection to store the addresses. Each individual element must support data binding, so you and I create a structure with the following common properties:

public struct AddressRecord
{
　private string _street;
　public string Street
　{
　　get { return _street; }
　　set { _street = value; }
　}
　private string _city;
　public string City
　{
　　get { return _city; }
　　set { _city = value; }
　}
　private string _state;
　public string State
　{
　　get { return _state; }
　　set { _state = value; }
　}
　 private string _zip;
　public string Zip
　{
　　get { return _zip; }
　　set { _zip = value; }
　}
}

Below, you will create this collection. Because we want type-safe collections, we're going to derive from Collectionsbase:

public class AddressList : CollectionBase
{
}