Data - Objects - Architectual Question

  • Thread starter Thread starter Uchiha Jax
  • Start date Start date
U

Uchiha Jax

I have a strongly typed dataset, within this dataset I have strongly typed
datarows, say for example a TaskRow which contains all of the information
about a task.
This TaskRow object is an excellent representation of the kind of
programming object I want to use in my program, it perfectly reflects the
database structure and has all of the properties I want, additionally if I
modify the structure I need only update the XML file and regenerate my
dataset.

The question is how do I expand this class? I want to add methods and
properties and would also like a definition that wasn't locked inside of the
DataSet type it is generated in.
Inheriting from the class seems impossible as it has the "hands off"
DataRowBuilder object as one of the constructor parameters and it whinges
whenever I try to specify a new constructor type.
If I don't inherit I end up just passing the DataRow into another object
which takes it as a parameter and just uses properties to forward requests
on the datarow:

e.g

TaskRow tRow;

public int TaskID
{
get{return tRow.TaskID;}
}

This feels clunky and wrong, as the new object is just a layer infront of
the other object and whenever the data gets updated I have to modify the
properties in the class.
Is this honestly the right way to do this or is there a better way?

Additionally I would assume it would be possibly bad to pass the datarow
into the logic section of the program as I understand that the Business
Logic and Data Tier should generally be kept seperate.
How is it that people deal with these problems on an enterprise scale? Does
everyone have methods that just perform conversion in the data layer? eg

public TaskObj GetTaskObject(TaskRow tRow)
{
TaskObj tObj = new TaskObj();
tObj.TaskID = tRow.TaskID;
return tObj;
}

Just seems wierd to write a bunch of methods that just copy properties,
seems inefficient for some reason.

Just want some advice from more learned individuals as i'm looking to take
on a large project pretty soon and still have these questions unanswered in
my mind.

Thanks for responding, if you do. :)

Kind Regards
Jax
 
Uchiha,

This is just preference, but I wouldn't try to attach the operations to
the typed DataSet. Rather, I would create classes that have the operations
on them, which you pass the data set through. Granted, it's not completely
OO, but it fits more with the nature of transactions an not maintaining
state (IMO).

Just my $0.02. Hope this helps.
 
Uchiha,

You can inhereit from the typed dataset and add additional methods to it,
not sure what you trying to do with the DataRowBuilder object, according to
MS documentation you should not use this object.
For example:

public class Tasks: TypedDataSet
{
//Additional properties...

public void Load()
{
//Load data from database to this.
}
public void Save()
{
//Save this object to database
}
}

So, you can access typed DataRow like this

Tasks tasksObject = new Tasks();
tasksObject.Load();
tasksObject.TaskRows.Rows[0].columnName = "something";
tasksObject.Save();

Hope it helps!

david
 
Hi Nicolas,

Thanks for the reply! :)

Just trying to work out what you are getting at, is this the idea?

public class TaskObj
{
public TaskObj(TypedDataSet ds, int id)
{
TaskObject t = new TaskObj();
TypedDataSet.TaskRow tRow = ds.Task.Rows.Find(id);
t.TaskID = tRow.TaskID;
t.SomeField = tRow.SomeField;
}
}

and then I suppose we have to go back the other way later....

public class TypedDataSet
{
public void UpdateTaskRow(TaskObj t)
{
TaskRow tRow = Task.Rows.Find(t.TaskID);
tRow.SomeField = t.SomeField;
///// then call a method to update the data
}
}

or do you mean this?

public class TypeConverter
{
public static TaskObj RowToObj(TypedDataSet.TaskRow tRow)
{
TaskObj t = new TaskObj();
t.TaskID = tRow.TaskID;
t.SomeField = tRow.SomeField;
return t;
}

public static void ObjToRow(TypedDataSet ds, TaskObj t)
{
TypedDataSet.TaskRow tRow = ds.Task.NewTaskRow();
tRow.TaskID = t.TaskID;
ds.Task.Rows.Add(tRow);
}
}


Nicholas Paldino said:
Uchiha,

This is just preference, but I wouldn't try to attach the operations to
the typed DataSet. Rather, I would create classes that have the operations
on them, which you pass the data set through. Granted, it's not completely
OO, but it fits more with the nature of transactions an not maintaining
state (IMO).

Just my $0.02. Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I have a strongly typed dataset, within this dataset I have strongly typed
datarows, say for example a TaskRow which contains all of the information
about a task.
This TaskRow object is an excellent representation of the kind of
programming object I want to use in my program, it perfectly reflects the
database structure and has all of the properties I want, additionally if I
modify the structure I need only update the XML file and regenerate my
dataset.

The question is how do I expand this class? I want to add methods and
properties and would also like a definition that wasn't locked inside of
the
DataSet type it is generated in.
Inheriting from the class seems impossible as it has the "hands off"
DataRowBuilder object as one of the constructor parameters and it whinges
whenever I try to specify a new constructor type.
If I don't inherit I end up just passing the DataRow into another object
which takes it as a parameter and just uses properties to forward requests
on the datarow:

e.g

TaskRow tRow;

public int TaskID
{
get{return tRow.TaskID;}
}

This feels clunky and wrong, as the new object is just a layer infront of
the other object and whenever the data gets updated I have to modify the
properties in the class.
Is this honestly the right way to do this or is there a better way?

Additionally I would assume it would be possibly bad to pass the datarow
into the logic section of the program as I understand that the Business
Logic and Data Tier should generally be kept seperate.
How is it that people deal with these problems on an enterprise scale?
Does
everyone have methods that just perform conversion in the data layer? eg

public TaskObj GetTaskObject(TaskRow tRow)
{
TaskObj tObj = new TaskObj();
tObj.TaskID = tRow.TaskID;
return tObj;
}

Just seems wierd to write a bunch of methods that just copy properties,
seems inefficient for some reason.

Just want some advice from more learned individuals as i'm looking to take
on a large project pretty soon and still have these questions unanswered
in
my mind.

Thanks for responding, if you do. :)

Kind Regards
Jax
Click to expand...
Click to expand...
 
I have the same question as Uchiha. To make the derived class useful, the
additional properties it adds to the base class should be available for
design-time binding to controls placed on forms. The problem is the
TypedTable and TypedRow properties embedded in the base class will not return
objects that expose the new properties (fields) added in the derived class.
I made another post about this same subject yesterday.

Basically, we need to:
a) Derive from a strongly typed DataSet class generated by the Dataset
Designer
b) Add new properties (e.g., "computed" columns) in the nested definition
for the typed row class.
c) Have both the original (base class) properties/fields *and* the
additional properties introduced in the derived class be available for
design-time binding in the WinForms Designer, when a DataSet of the derived
type is placed on the form.

Has anyone done this? If so, is there an URL for an example?
 
"b) Add new properties (e.g., "computed" columns) in the nested definition
for the typed row class."

You can not alter the designer generated typed DataRow class,
not sure what you trying to do on the columns, but you can do some basic
operations
using the Expression property on the DataRow. You can define an
Expession when you
creating the typed DataSet in the designer.

david




kaborka said:
I have the same question as Uchiha. To make the derived class useful, the
additional properties it adds to the base class should be available for
design-time binding to controls placed on forms. The problem is the
TypedTable and TypedRow properties embedded in the base class will not return
objects that expose the new properties (fields) added in the derived class.
I made another post about this same subject yesterday.

Basically, we need to:
a) Derive from a strongly typed DataSet class generated by the Dataset
Designer
b) Add new properties (e.g., "computed" columns) in the nested definition
for the typed row class.
c) Have both the original (base class) properties/fields *and* the
additional properties introduced in the derived class be available for
design-time binding in the WinForms Designer, when a DataSet of the derived
type is placed on the form.

Has anyone done this? If so, is there an URL for an example?


David Lei said:
Uchiha,

You can inhereit from the typed dataset and add additional methods to it,
not sure what you trying to do with the DataRowBuilder object, according to
MS documentation you should not use this object.
For example:

public class Tasks: TypedDataSet
{
//Additional properties...

public void Load()
{
//Load data from database to this.
}
public void Save()
{
//Save this object to database
}
}

So, you can access typed DataRow like this

Tasks tasksObject = new Tasks();
tasksObject.Load();
tasksObject.TaskRows.Rows[0].columnName = "something";
tasksObject.Save();

Hope it helps!

david
Click to expand...
Click to expand...
 
Back
Top