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

Re: hit a design roadblock by Uri

Uri
Thu Oct 21 04:41:47 CDT 2004

Why can't you use a typed dataset?

SteveK wrote:
> 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
>
>
>
>