S
SteveK
OK, I am developing a client application that will present data to the user.
Nothing fancy.
I had intended to retrieve pretty much all the data in a DataSet, then
filter and sort locally on the client to cut back on trips to the DB.
I also had decided to abstract my data from the DataSet by maintaining
collections of business objects that would represent the various records
retrieved from the DB. Each business object has a reference to the DataRow
in the DataSet that is represents. The class is basically a set of
properties to access the data in a typed fashion as well as a collection of
methods to simplify interaction with the various records and the many tasks
that a user will perform(open files, print, etc, etc)
I started development of the migration tool that will migrate our existing
database from a flat, binary file format into a relational DB. Basically I
parse the binary file, then loop through the records and for each one I
create all the required records in the rel. DB and move on, pretty straight
forward..... until I realized that my business object are really crippled
when not constructed in the context of a Query - When I query the DB, I pass
the current DataRow from the result DataSet to the business object
constructor, then that object is ready to go. My assessors can safely
assume that there is, for example a column named "TakeNr" since "TakeNr" was
returned from the original query.
I hit a roadblock. When created a business object out of the query context,
for example in the migration tool mentioned above, I have not queried the
rel. DB yet, so I don't have a DataTable to create a new DataRow from. I
found myself creating a DataTable, adding DataColumns(the ones that I could
think of) then making a call to DataTable.NewRow() to finally get that
DataRow that will hold the data.
This whole last step seems really lame. It made me thing that my original
approach of having a reference to the base data inside the business object
isn't quite as slick and powerful as I once thought it was. I am now in a
design tailspin, not sure what to do.
If anyone has any thoughts, experiences or tips, please share.
Thank You,
Steve Klett
Nothing fancy.
I had intended to retrieve pretty much all the data in a DataSet, then
filter and sort locally on the client to cut back on trips to the DB.
I also had decided to abstract my data from the DataSet by maintaining
collections of business objects that would represent the various records
retrieved from the DB. Each business object has a reference to the DataRow
in the DataSet that is represents. The class is basically a set of
properties to access the data in a typed fashion as well as a collection of
methods to simplify interaction with the various records and the many tasks
that a user will perform(open files, print, etc, etc)
I started development of the migration tool that will migrate our existing
database from a flat, binary file format into a relational DB. Basically I
parse the binary file, then loop through the records and for each one I
create all the required records in the rel. DB and move on, pretty straight
forward..... until I realized that my business object are really crippled
when not constructed in the context of a Query - When I query the DB, I pass
the current DataRow from the result DataSet to the business object
constructor, then that object is ready to go. My assessors can safely
assume that there is, for example a column named "TakeNr" since "TakeNr" was
returned from the original query.
I hit a roadblock. When created a business object out of the query context,
for example in the migration tool mentioned above, I have not queried the
rel. DB yet, so I don't have a DataTable to create a new DataRow from. I
found myself creating a DataTable, adding DataColumns(the ones that I could
think of) then making a call to DataTable.NewRow() to finally get that
DataRow that will hold the data.
This whole last step seems really lame. It made me thing that my original
approach of having a reference to the base data inside the business object
isn't quite as slick and powerful as I once thought it was. I am now in a
design tailspin, not sure what to do.
If anyone has any thoughts, experiences or tips, please share.
Thank You,
Steve Klett