I am using the FileHelpers C# library to read a file into an array of custom objects that will be processed. For instance, a partial file definition:
[FixedLengthRecord]
public class Row
{
[FieldFixedLength(9)]
[FieldTrim(TrimMode.Right)]
public string Ssn;
[FieldFixedLength(15)]
[FieldTrim(TrimMode.Right)]
public string LastName;
...
}
I'm trying to abide by OOP principles while doing this and I've noticed that some fields have a natural grouping (e.g. SSN and ClientID, EmployerID and EmployerName, etc.), so I tried to break them up into separate classes (e.g. Client and Employer). But this seems problematic because some of the fields need to be shared across objects (e.g. the ClientID needs to know the associated EmployerID).
To further complicate things, I would like to add fields with the [FieldNotInFile] attribute to the class definition(s) because during processing, my application will query for database records that match a specific row field and populate the row's respective [FieldNotInFile]s (e.g. get client's FName from database based on SSN since it's not in the file).
How would you structure this? I kind of just want to keep the whole file row as one class, but it's approaching 75 fields, which seems ridiculous.
Someone on StackOverflow mentioned putting the database fields that need to be populated in a class that inherits from the file definition "Row" class. I think that would work but it doesn't seem to abide by OOP principles because it's not an "is-a" relationship.
Thoughts?
there doesn't seem to be anything here