My way of working with data in .NET 1.x is using typed datasets. I have a library which creates typed dataset objects and fills them using one (ore more !) sqladapaters. On the web form I have a dataset component to which the web controls are bound. It takes some plumbing to get the data in and out of the database to the dataset on the form but it works very well. New to Whidbey are the datasources which will do all the plumbing for you. All very quick, but most of them are somewhat dirty. You drop a database table from the server explorer on the web-form and get a fully editable browser grid without writing a line of code. To enable the edit you have to set the GridView's AutogenerateXXbutton properties to true. Nice, but the problem with that is that the code on the form directly connects to the database. No multi-tier and it will not scale very well.

A neater way is to create datacomponents for your database interaction. The objectdatasource will do the plumbing to connect a gridview (or other data-aware component) to the data-component. The datacomponent is a somewhat strange creature. It is an xsd file and wraps up the schema for the dataset. VS will generate the typed dataset class. A datacomponent also wraps up tableadapters. These are best compared to the sqldata-adapters in 1.x. For every query result set (having the same columns) in the datacomponent the wizard generates a tableadapter class. So if you have two tables in the datacomponent, say invoices and invoicelines the wizard will generate three classes (containing loads of helper classes), one for the dataset, one for the tableadapter to retrevie an invoice-row and one for the tableadpater to retrieve the invoice-lines. A new query selecting a single invoice is part of the same tableadapater as the query returning all invoices.

The catch is that most datasources, including the objectdatasource, work with one table of data. The objectdatasource binds to the tableadapaters, not the dataset. So to work with a multi-table dataset you need multiple datasources. There were two datasource components in 2005 which can work with a multiple table dataset. First comes the DataSetDataSource, it has a method to get the datset wrapped up, it doesn't have a method to set it. You have to fill it from an XML file or string. The component will be dropped in the next VS 2005 beta; most functionality is also in the XMLdatasource component. That component has no dataset aware properties at all, again you have to fill it from file or string. To get database data in and out requires writing your own plumbing again. As every dataset is an XML document and every well formed XML document can be treated as a dataset that is a do-able job. But it is a far cry from the ease of the other datasources.

Typed datasets are quite nice at design time. You layout the columns of the grid and the like right from the datsets's definition. In 2003 it is from the dataset's definition, in 2005 it is from the tabeladapters defintion. A nice target for a multitable dataset is a treeview. It accepts an xmldatasource in the properties you can assign the schema of the xml-documents. Alas the designer will not get a clue of the contents of the schema, you have to edit the databindings of the tree-nodes all by hand.

A lot has changed in 2005. It is good to see how most of the boring plumbing code is generated. But I'm not that happy how the dataset itself has moved out of  focus in favor of the tableadapater. I do use a multi-table dataset and writing plumbing for them hasn' t become easier at all.

Peter

.