I've been giving some thought to the typed DataSet debate recently. For the most part my preference has been to use untyped DataSets because frankly it is easier to not have to worry about synching database and code every time a change is made to the database.

For a long time I've completely ignored typed DataSets, but last week I dug in and took a closer look at what is really involved to make this work in applications.

There's no doubt that typed DataSet provide a good amount of functionality and make some things easier. However, what I found is that If you are using business objects that provide a generic data abstraction layer you end up having to some work to have typed DataSet work within that framework.

Particularly you have to make sure that you pre-create your DataSet before letting the framework code create one for you so that framework knows to use your typed DataSet. The biggest problem is that you can't recast a typed DataSet from a regular DataSet, but the data must be loaded into it from the start. This is no big deal if you do this in normal front end data code but requires some setup in a business object environment.

For my business objects this means something like:

public class busCustomer : wwBusiness

{

public busCustomer()

{

this.Tablename = "wws_customers";

this.ConnectionString = App.Configuration.ConnectionString;

this.DataSet = new dsCustomers();

}

…

}

Not a big thing, but remembering this and enforcing it at all business objects is an issue.

Probably the biggest issue I see is related to work flow with typed DataSets. You generate typed DataSets by dropping tables onto the XSD designer or manually building XSD definitions. The process is not difficult but if you have a lot of tables that change frequently synchronizing the DataBase and the schema for the typed DataSet becomes a big issue.

You have to manually drop the tables onto the XSD designer to get the generation to occur. This means you have to manually manage the schema from which the DataSet is generated. Make a change to the database and you have to make sure you remember that the XSD is also updated. To make things worse in my environment every business object uses its own DataSet, so I would tend to require many separate XSD files (essentially one or more for each table that a business object 'owns').

The other issue I have with the typed DataSet is that if you look at the code generated there's a fair amount of overhead. Specifically the first time run a query and fill a table all the tables are created along with their column definitions. Although this provides a good typed interface there's a fair amount of overhead here that is incurred everytime you instantiate and load data into the typed DataSet. While this may be OK in Windows Forms apps in a Web app the constant reloading will occur a fair amount of overhead.

As a review: To get a DataRow then you have to do something like this:

// *** Noramlly you'd do this in the bus obj

// *** for demo do raw Execute here

int Result = Customer.Execute("select pk,Address from wws_customers","wws_customers");

// *** Standard DataRow access

Customer.DataRow = Customer.DataSet.Tables["wws_customers"].Rows[0];

string Company = (string) Customer.DataRow["Company"];

Customer.DataRow["Company"] = "13 Hanalou Road";

// *** Typed Data Row access

dsCustomers.wws_customersRow CustRow = (dsCustomers.wws_customersRow) Customer.DataRow;

Company = CustRow.Company;

CustRow.Address = "32 Elm Street";

It seems to me that the key feature of a typed DataSet is the typed DataRow. The rest of the functionality that the typed DataSet is useful but not crucial and frankly not worth the overhead IMHO.

One way to approach this might be to build something a bit simpler - something like a wrapper for a DataRow that can be assigned on an as needed basis.

I'll have more on this topic in the next entry...