2

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
Anders
  • 17,306
  • 10
  • 76
  • 144

1 Answers1

3

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...

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • I was a bit unclear in my question the question is more oriented about creating the object once I have the mapping info. The contract is set so I do not need to mark the properties with custom attributes. When you say IL ready baked IL you mean someting in the lines of http://www.codeproject.com/Articles/14560/Fast-Dynamic-Property-Field-Accessors – Anders Sep 10 '13 at 10:53
  • @Anders well, maybe not something *quite* like that, but yeah, something that avoids calling `SetValue` on `FieldInfo` / `PropertyInfo` too often. But : if you're only doing this occasionally, even this isn't a pain point,. – Marc Gravell Sep 10 '13 at 11:23
  • Its about 1000 records in a result, each record have 10-30 columns so a max of about 30 000 properties has to be set + 1000 CreateInstance. Do you have a blog or a article about IL baking? its not something I have used, thanks. – Anders Sep 10 '13 at 12:01
  • @Anders for those numbers, I'd start simple - get it working with SetValue - then only get excited about performance if it looks too slow – Marc Gravell Sep 10 '13 at 12:10