Here’s a scenario I’ve encountered variations of on many occasions.

Imagine an XML feed which displays data about three different types of event: concerts, plays and movies. Each has a different set of parameters. We want to scrape this information and store it for our own purposes. So we create a database which has application data and three tables for this data which we’ll call event_concert, event_play and event_movie. We stick an ORM over the top.

Every hour we poll the feed, looking for new data, and saving it in our database. Because our ORM creates typed objects, there are essentially two ways we can do this.

First, write three separate functions, one for each object type, which create and populate the necessary object, and put it in the database. This is clean and easily understandable. But it’s more code to write and it’s not necessarily the best for maintenance, since new functions muse be added to deal with new object types and there’s a risk of duplicated code.

Second, write a single loop which uses reflection various functions from the ORM context to iterate over the object types (using a fixed prefix like event_ to recognize them), and then iterates over the properties to populate them before saving to the Db. This is messy and hard to understand, but done right it should be a fire-and-forget option that will semi-automatically pick up and deal with new object types with a minimum of fuss.

In this example it’s easy to go with the first option since there are only three objects to save. But what if there’s five? Or fifty? Or more? Suddenly handling all those different objects with their own custom functions doesn’t seem so attractive any more.

Is there any other approach or design pattern which achieves a similar outcome and is both clean and capable of dealing with lots of object types?