Is there a better design than reflection to deal with large numbers of ORM objects?

Question

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?

---

Here's an example of what I mean in pseudocode.

If we treat the objects as different types:

GetAndInsertConcerts();
GetAndInsertMovies():
GetAndInsertPlays();
// if we need a fourth object type, we'll need to add a new function

public void GetAndInsertConcerts()
{
    var xmlConcerts = GetObjectsFromXML("Concerts");

    foreach(var xmlConcert in xmlConcerts)
    {
        Event_Concert c = new Event_Concert(xmlConcert);
        repository.InsertAndSave(c);
    }
 }
 // the functions for plays and movies will repeat this structure

And the second approach:

string[] eventTypes = repository.GetTablesStartingWithEvent();

foreach(string eventType in eventTypes)
{
    string xml = GetXmlForEventType(eventType);
    // BuildObjectFromXml function is reflection based, likely hard to code & to follow
    var obj = BuildObjectFromXml(xml);  
    repository.InsertAndSave(obj);
}

Worth repeating - the boilerplate in the first approach is fine if you're dealing with a handful of object types you don't expect to change. But writing repeat "get and save" functions for a lot of different object types is going become tiresome.

Answer 1

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

Really? It sounds to me that the elephant in the room is impedance mismatching.

Your scenario has two databases: the first I assume to be owned by someone else; you have access to it only via exported XML. The second you own, and access with the ORM. If the schema of the first database changes, how do you detect the change? The fire-and-forget strategy seems like it would either silently corrupt your database or it would start throwing exceptions which you haven't planned to handle.

Your ORM works either by reflection or by generated code. Your question is how to handle the mapping from the XML to objects. For maintainability, the answer is surely that if your ORM uses reflection then you should use reflection, and if your ORM uses generated code then you should use generated code. That way the maintainance programmer has to deal with fewer inconsistencies.

Either way, I would use a schema for the XML (writing one myself if the supplier of the data doesn't supply one) and add compile-time and run-time checks that the schema of the XML matches the schema of the ORM, as well as a run-time check that the XML received matches the schema. In case of mismatches you want some notification: I would fail compilation in the compile-time check and send myself an e-mail in the run-time checks.

Finally, the list of object types to handle should be in a config file. Reconstructing it from the database means that you can't decide to stop handling a given type of event without losing existing data.