Question On Using Strongly-Typed Datasets

  • Thread starter Thread starter C Newby
  • Start date Start date
C

C Newby

When using a strongly-typed dataset, it seems to me that a logical extension
would be to associate the dataset with a logical system and treat the
associated strongly-typed tables and rows as system-wide collections and
objects respectively. In this sense, the strongly-typed dataset and its
associated objects simply define the language by which the different parts
of an application speak, most specifically to and from a data access layer,
and in this way might be used as a substitution of a more traditional object
model/hierarchy. (My opinion anyway)

For example, suppose I have a strongly-typed dataset called
"PhonebookSystemDS" that contains a table called "PhonenumberTable" that in
turn contains records that are phonenumbers or instances of the
"PhonenumberRow" object. This is all well and good, and I have no initial
problem setting this up. However, then I try to add an "AddPhoneNumber"
method to one of my public interfaces. Well, adding the interface is
actually not the problem, but it looked something like:

public AddPhoneNumber( PhonenumberRow Phonenumber )

It is when I try to consume this feature from another application layer that
I ran into problems. Given the following:

....
PhonenumberTable newPhonenumberTable = new PhonenumberTable();
PhonenumberRow newPhonenumber = new PhonenumberRow();
newPhonenumber.Name = "John Smith";
newPhonenumber.Phonenumber = "XXX-XXX-XXXX";
newPhonenumberTable.AddPhonenumberRow( newPhonenumberRow );
....

This gives two compile errors:
'PhonenumberTable()' is inaccessible due to its protection level
No overload for method 'PhonenumberRow' takes '0' arguments

Upon inspection of the code behind for my dataset, I can clearly see how
this is the case. However, my questions revolve more around "why" this
happens, clearly, by design.
Am I simply trying to use strongly-typed datasets for something they are not
intended?
If not, how might I better structure my interfaces without having to do
things like enumerate properties or creating wrapper classes?
What exactly are the pros and cons of modifieing the dataset code-behind?
What exactly are the reasons for strongly-typed datasets having this default
behavior?

I would greatly apreciate any guidance. TIA//
 
I believe that when adding a new row, you must first get the row from an
instance of the table where it is defined, rather than just creating a row
and
then adding it. Here is some (totally untested) code that I believe works:

Dim lotSizeDS As New LotSizerDS

lotSizeDS = LoadData(scenarios)

Dim newWCRow As LotSizerDS.WorkCentersRow

Dim wcTable As LotSizerDS.WorkCentersDataTable

newWCRow = wcTable.NewWorkCentersRow

wcTable.AddWorkCentersRow(newWCRow)

If you were to adjust the code-behind for the dataset, you would
lose your changes any time you were to re-generate it. So, unless
you are absolutely confident your schema will not change, this might
not be a great idea. An alternative might be to create a new class
which inherits from the typed dataset, and put your custom code
in there. This would prevent your changes from being lost, and would
only require updates to the dependent class when the interface of the
base class changes.

Mike
 
Back
Top