DataObject overhaul

[jordansparks]

I'm seriously thinking about a minor overhaul of the DataObject base class. I would like to get rid of all the bool ...Changed property clutter. I would like to move it to the level of the DataObject class by storing it as a private collection of changed field name strings. This would also allow us to move the MarkDirty as well as simplify testing for whether the value has actually changed. So instead of:

Code: Select all

[DataField("FName")]
private string fName;
bool fNameChanged;
/// <summary>First name.</summary>
public string FName {
	get { return fName; }
	set { if(fName!=value){ fName = value; MarkDirty(); fNameChanged = true;} }
}
public bool FNameChanged {
	get { return fNameChanged; }
}

it might look more like:

Code: Select all

[DataField("FName")]
private string fName;
/// <summary>First name.</summary>
public string FName {
	get { return fName; }
	set { FieldChanged("fName",value); }
}

I''ve sent an email to Frederik Carier asking him for his opinion. Finally, I don't know if it's even possible or how hard it will be.

[dwkrueger]

[DataField("FName")]
private string fName;
/// <summary>First name.</summary>
public string FName {
get { return fName; }
set { FieldChanged("fName",value); }
}

Try this
class BaseObject
{
private string _val;
private bool _IsDirty;
public string VAL
{
get { return _val;}
set if(_val!=value){ _val= value; _IsDirty = true;}
}
public bool ISDIRTY
{
get { return _IsDirty;}
}


}

[DataField("FName")]
/// <summary>First name.</summary>
BaseObject fname;
public string FName {
get { return fname.VAL; }
set { fname.VAL= value; }
}

Just a thought.

[jordansparks]

It's a good idea. Maybe I'm just old and stupid, but I always have trouble remembering heirarchy when objects inherit. For this reason, I try really hard not to use inheritance or interfaces. I just find them really annoying because I frequently get lost in the maze of code.

So, keeping that in mind, and looking at your suggestion, I'm trying to picture how hard it would be to implement it. I would have to think of a really good name for the base class, something descriptive, like maybe BaseDataField. Then, I'm trying to visualize if I could just replace things in an incremental fashion rather than forcing an entire rewrite. I would have to think about how to handle types other than strings. There are two quick ways I can think of:
1. Have multiple BaseDataFields, such as BaseDataFieldString, BaseDataFieldInt, BaseDataFieldBool, etc.
2. Make VAL an object rather than a specific type.
I would lean towards option 2. They would both add approximately equal complexity.

I've been staring at it for quite a while, and I think I really really like your suggestion. Thank you.

[dwkrueger]

I agree with it is hard to keep track of. I have seen similar concepts in other code projects and it is especially difficult for a new person on the project to get the mind wrapped arround. I think this is why more verbose commenting is important (provided you have the time). Also I have not master it but apparently there is a way to export the comments of the code into an xml file then make a code help documentation from this xml file. I have fiddled with NDoc but I have had no success.

As far as inheritence goes I know that something like this you really want to think throu before you implement this. I think inhertance works well when you really don't have to think about it much. That is when you know you have a good flow.

Okay I'm looking at this and just had another thought. If _val was an object then we have to type out all of the inherited classes, or overide the VAL Property. Also if you put value data (ie non referenced data types such as int, decimal, float, bool, a struct, etc) you are okay but if you put referenced data the the comparison will naturally compare references not values.

What about using Generics. I know there is a way to define you own generic. So everywhere there is an object it is now <T>. Then I think you would get away from the inheritance completely. Obviously I don't know how to implment this but the concept seems right.

class ODBaseObject
{
private <T>_val;
private bool _IsDirty;
public <T> VAL
{
get { return _val;}
set {
if (_val is string )
{ if (string comparision is different) _val= value; _IsDirty = true;}
else if(_val!=value)
{ _val= value; _IsDirty = true;}
}
public bool ISDIRTY
{
get { return _IsDirty;}
}

[jordansparks]

Right. Generics is the obvious solution for that. I'm not sure how high of a priority this is. Nobody's going to notice. And I sort of like the old way of doing it, where we have nice simple public fields for each data table column. But I think at least we do now have an improved version that we can consider implementing at some point.