Question

I am currently writing a plugin to a CAD style software. The plugin does calculations based on data read from the CAD model and a lot of table lookups (think printed tables in a calculation guide). I inherited this plugin and the current solution defines a class Constant which has a bunch of static struct members and two-dimensional arrays. These arrays are then indexed by enum values at runtime to find the appropriate data.

I’m not too happy with the solution, as the representation in the Constant class is kind of hard to read – the enum values used when retrieving data are of course not visible when editing the data (although that only ever happens manually and very seldom).

I’d prefer not to bundle a DB (and engine) with a small plugin, but would like similar semantics, for instance using LINQ to select values where some fields match etc.

What is your preferred solution to this problem?

• do you use a bunch of XML files and parse them at runtime?
• do you use a templating engine (t4?) to generate classes from XML files at compile time?
• do you store XML versions of datasets in the resources (read ’em in at runtime, LINQ to dataset…)
• would you just keep the Constants class, maybe add some documentation to the members (don’t get me started about legacy code with no comments whatsoever…)

Answer 1

I’m doing that at the moment for a performance-critical application. The way I do it is by serializing the data in a flat file (as part of my release process), then (at launch) deserializing it into a class model, allowing LINQ-to-Objects querying.

In most scenarios xml would be reasonable, but by preference I’m using my own binary serializer – mainly for speed.

Since the constant data doesn’t change, it is usually fine to cache it away in an instance you keep handy and re-use many times (rather than deserialize it per use).

To clarify: the data to use is stored in a standard database (they are good at that type of thing, and lots of tools exist for import / edit / query / etc). As part of my release process, I load the data into the object model (using the same classes) from the database, and serialize it:

// during release
MyDataModel data = new MyDataModel(); // wraps multiple data lists
data.Load(); // from database tables, using ORM
data.Save("data.bin"); // serialization

then I ship data.bin with the app (well, actually it is stored separately, but that is an aside…); and at runtime:

MyDataModel data = new MyDataModel();
data.Load("data.bin"); // deserialization
data.Freeze(); // make immutable

Note that in this case, the data is “popsicle immutable” – i.e. to preserve the “constant” nature (but while letting it edit the data during load), I have a cascading Freeze method that sets a flag on the items; once this flag is set, all edits (to items or to lists) throw an exception. This has zero performance impact or the running code: since you expect to treat it as constant data, it only does reads!