Strongly Typed DataSets

[Ken Allen]

I have read a bit about the strongly types DataSets, and the only
purpose/value that I can see for them is the ability to write code that
references the contents of such a DataSet in a more convenient manner. There
are three (3) significant issues I see with the use of strongly types
DataSets:

1. There does not seem to be an easy way to synchronize changes to the
actual database schema.

2. There does not seem to be a convenient way to add business rules to these
derived DataSets that will not be erased by the wizard re-generating the
source code.

3. It seems that every definition is actually expected to be a single table.
3a. I can add multiple tables to the strongly types DataSet, but it is not
trivial to instantiate only one table and manipulate it, especially with
respect to (1) and (2) above.
3b. There does not seem to be a way to define relationships between multiple
tables in a strongly typed DataSet.

Am I correct on these points? If not, where can I find information on how to
deal with these issues?

-ken

 

[David Browne]

I have read a bit about the strongly types DataSets, and the only
purpose/value that I can see for them is the ability to write code that
references the contents of such a DataSet in a more convenient manner.

It cleans up your source code, gives you better type safety, and turns a
whole bunch of runtime errors into compile-time errors.

There
are three (3) significant issues I see with the use of strongly types
DataSets:

1. There does not seem to be an easy way to synchronize changes to the
actual database schema.

Yes, this is a problem. I had to write a small program to generate the
datasets from my DB schema.
But typed datasets make the schema changes easier on the whole, since when
you change the DataSet the compiler will tell you what else has to change.
With an untyped DataSet you have to search the source for stuff like

int i = (int)ds["myColumn"]

This has two problems. If you change the name of the column, or the type,
you won't get an error until runtime.

2. There does not seem to be a convenient way to add business rules to these
derived DataSets that will not be erased by the wizard re-generating the
source code.

Write a subclass of the DataSet. When the DataSet is regenerated, all your
code in the derived class is preserved.

3. It seems that every definition is actually expected to be a single table.
3a. I can add multiple tables to the strongly types DataSet, but it is not
trivial to instantiate only one table and manipulate it, especially with
respect to (1) and (2) above.

You can add just one if it does not depend on other tables. A DataSet will
typically have one "main" table and zero or more related tables. You can
always populate just the main table.

3b. There does not seem to be a way to define relationships between multiple
tables in a strongly typed DataSet.

Sure there is. Just use the DataSet designer to create keys, and then
relationships. This has the added benefit of creating indexes on the
DataTables, and enabling easy navigation among related rows.

See:


Using Annotations with a Typed DataSet
http://msdn.microsoft.com/library/d...tml/cpconusingannotationswithtypeddataset.asp

David

 

[Ken Allen]

OK, I can see some of this as being useful, although complex to generate and
manage.

I have inlined some more comments.

-ken

I have read a bit about the strongly types DataSets, and the only
purpose/value that I can see for them is the ability to write code that
references the contents of such a DataSet in a more convenient manner.

It cleans up your source code, gives you better type safety, and turns a
whole bunch of runtime errors into compile-time errors.

There
are three (3) significant issues I see with the use of strongly types
DataSets:

1. There does not seem to be an easy way to synchronize changes to the
actual database schema.

Yes, this is a problem. I had to write a small program to generate the
datasets from my DB schema.
But typed datasets make the schema changes easier on the whole, since when
you change the DataSet the compiler will tell you what else has to change.
With an untyped DataSet you have to search the source for stuff like

int i = (int)ds["myColumn"]

This has two problems. If you change the name of the column, or the type,
you won't get an error until runtime.

OK, I see the benefit of the strongly typed DataSet, but using it for
anything other than a mature schema would be a real problem!

Write a subclass of the DataSet. When the DataSet is regenerated, all your
code in the derived class is preserved.

Yes, I can see how that would work. Not a bad solution, especially if the
first issue were less of a problem!

You can add just one if it does not depend on other tables. A DataSet will
typically have one "main" table and zero or more related tables. You can
always populate just the main table.

OK, so each strongly typed DataSet should only contain related tables.
Acceptable.

Sure there is. Just use the DataSet designer to create keys, and then
relationships. This has the added benefit of creating indexes on the
DataTables, and enabling easy navigation among related rows.

See:


Using Annotations with a Typed DataSet
http://msdn.microsoft.com/library/d...tml/cpconusingannotationswithtypeddataset.asp

David

I have read the reference material, and I have reviewed the designer, and I
did trip over the mechanism.

Thanks.