Mainframe Flat file to C# classes

Question

I have to communicate with a IBM main frame using IBM WebSphere. The service on the main frame side can only use flat files.

On my side I want to use CQRS (Command / Query)

In other words I want to serialize command / queries and deserialize query results

I could do it with standard reflection offcourse, but my question is if there is a nicer way of doing it?

Can I make use of dynamics?

Flatfile > ParsedObjectStructured > Dynamic type > static type

Answer 1

This would depend an awful lot on what the format of the flat file is, and how the schema works - is it self-describing, for example? However, it sounds to me like most of the work here would be in understanding the flat-file format (and the schema-binding). From there, the choice of "deserialize into the static type" vs "deserialize into a dynamic type" is kinda moot, and I would say that there is very little point deserializing into a dynamic type just to have to map it all to the static type. Additionally, the static type can (again, depending on the file-format specifics) be a handy place to decorate the types to say "here's how to interpret this", if the file-format needs specification. For example (and I'm totally making this up as I go along - don't expect this to relate to your format):

[Frobber(Offset = 4, Format = DataFormat.LittleEndianInt32)]
public int Id {get;set;}

[Frobber(Offset = 0, Format = DataFormat.LittleEndianInt32)]
public int Index {get;set;}

[Frobber(Offset = 8, Format = DataFormat.FixedAscii, Size = 20)]
public string Name {get;set;}

[Frobber(Offset = 28, Format = DataFormat.Blob)] // implicit Size=16 as Guid
public Guid UniqueKey {get;set;}

where FrobberAttribute is just something you might invent to specify the file format. Of course, if the schema is defined internally to the file, this may not be necessary.

Re reflection: basic reflection will work fine if the data is fairly light usage; but overall, reflection can be quite expensive. If you need it to be optimal, you would probably want the implementation to consider strategy-caching (i.e. only doing the discovery work once) and meta-programming (turning the strategy into ready-baked IL, rather than incurring the overhead of reflection at runtime).

If the file format is a common / popular one, you might find that there are existing tools for reading that format. If not, you can either roll your own, or find some crazy person who enjoys writing serialization and meta-programming tools. Such people do exist...