My objective is to encapculate each DataColumn in properties, so that each
developer does not need to know the database structure i.e. column names.
I do something like:
For Each row as DataRow in MyTable.Rows
myUserCollection.Add (New User(row))
Next
currentUser = myUserCollection(2)
MessageBox.Show("Current User Name: " & currentUser.UserName)
As you can see, there is less code to populate the User class. You can even
implement the RowState property, to show the state of the class. When the
class is modified, it reflects this. When saving, you can easily update the
DataTable and using the DataAdapter, update the actual database.
These are my reasons.
L.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:Ou**************@TK2MSFTNGP09.phx.gbl...
Landley,
What is the reason of using only one datarow in a dataset?
This is (as always when I do that) a real question, I have the idea I miss
something.
I would forget the matter of spead, the dataset is as well readed by the
datareader, so that will be probably in for us for one read unmeasurable
time unitys.
Cor
"Landley" <ne**@creations-software.co.uk>
I have created some classes that have a datarow as a datasource and
properties for reading from or writing to the datasource (see example
below). I have used this solution to separate the data layer, so the
2nd hand developer does not need to know the data structure.
1. I create a dataset based on a SQL statement
2. I retrieve a datarow from the result(s) and pass the row as an
argument in a class constructor.
3. In the class constructor, I set the datasource.
4. Each property refers to each column in the datarow.
Are there any issues that I should be made aware of using this method?
Would this method perform faster that iterating through a datareader,
instantiating a class and populating each property in turn?
L.
