Recommended Implementation For Fields From Another System With Non-.Net Data Types

Question

I am reading data from another system that returns XML that provides the following information for each field: "Field Name", "Data Type", and "Size". The "Data Type" returned is either: Alpha, LAlpha, RAlpha, CAlpha, or Numeric. Sometimes there are other attributes returned as well, such as Casing. I would like to create objects to model the data returned and also have to generate xml with element values formatted according to the given data type to send back to the other system to perform transactions. I started off creating an object that would represent each property on the object like:

//Type T represents the data type of the Value property
public class OtherSystemField<T> : IOtherSystemField{ 

public string OtherSystemFieldName { get; set;}
public OtherSystemDataTypeEnum OtherSystemDataType { get; set;}
public int Size { get; set;}
public T Value { get; set;}
public string ToOtherSystemString() { ....};

}

//Class using the data field
public OtherSystemEntityClass {

public OtherSystemField<string> f1 { get; set; }
public OtherSystemEntityClass () {
f1 = new OtherSystemField<string>() { 
OtherSystemFieldName = "x", Size = 4, OtherSystemDataType = ...};
f1.Value = "DefaultStringValue"; 
}
}

The question is does this representation of the other system's data fields make the most sense, using this type of object to model a field from the other system instead of a .Net data type property that is associated with some meta-data?. Any opinions on, say, having the property have attributes containing these values like:

public OtherSystemEntityClass {

[OtherSystemFieldName("SomeFieldName", 5, OtherSystemDataTypeEnum.RAlpha)]
public string f1 { get; set; }

}

Here is an example of the XML:

<COLUMNS>  
<COLUMN header="FieldX" dspname="FieldX" dbname="FIELDX" type="NUMERIC" size="4" /> 
<COLUMN header="FieldY" dspname="FieldY" dbname="FIELDY" type="ALPHARIGHT" size="14"/>        
</COLUMNS> <COLS> <COL><![CDATA[ 1000]]></COL> <COL><![CDATA[ 102]]></COL> </COLS>

I look forward to everyone's feedback - I have no doubts I will hear good perspectives. Performance is not of a huge concern, as the number of fields is relatively small. Also, this is implemented in .Net 3.5

Answer 1

Do you already know the Field Name, Data Type, Size, etc of your fields or is this something that you need to determine at run time? If you already know all the information about the fields at design time, then I like the attribute approach. I've done the very same when dealing with incoming Xml from old systems. You can then deserialize the Xml to your objects, and you're good to go.

If you do not know the format of the Xml at design time, that is, you need to set the attribute values at run time, then using attributes will be more difficult than your first approach. You would need to set the attributes with reflection, which would be more work than just setting a property in the first solution.

Answer 2

I'm not sure what the "Alpha" types are, but the newly-added XML snippet is clearly describing a table schema. If you can pull off a mapping, I might actually use a DataTable instead of creating any custom classes at all.

I wouldn't be too surprised to find out that the XML is literally serialized directly from something similar to a .NET DataSet/DataTable but in a different language/platform. Those CDATA tags are not consumer-friendly. But if you can map Alpha values to some enum type (most likely a custom one you create), then you can just add a column of that type to a DataTable.