Asynchronously loading a domain model

Question

I have started a small project to properly teach myself about a number of things: domain driven development and inversion of control are the ones that apply in this case.

I have decided to write an application that can load and visualize timing data from sports events (I have access to quite a lot of this type of data).

One requirement is that I want to be able to select from a number of different data sources, some of which are full details of an event (CSVs produced after the event), and some of which are live data sources.

I am having trouble designing the process that loads this data into the domain so that it can be easily used for both synchronous and asynchronous loading.

I'm guessing I need an abstract class that all Data Sources derive from. This class needs to be able to set itself up (get the path of the data file, or the address of the live data source server), and I guess it needs to look something like this:

protected abstract void Setup();
protected abstract void LoadData(Race race);

public Race Load()
{
    Race race = new Race();
    Thread t = new Thread(new ParameterizedThreadStart(LoadData));
    t.Start(race);
    return race;
}

Each data source can then implement their own setup method, but this feels wring, I don't like the idea of the data source class showing a dialog or something because it just feels wrong.

They can also implement their own LoadData method that populates the domain, in the case of a live source this will be long running, and will put in lap times as they occur, a full data source will just populate the model as fast as it can.

However the front end will have immediate access to the race object, and can bind to its events. Is it better to pass the race object into the load method so that the events can be set up beforehand?

I just want to know if this design looks ok. Its feels slightly strange to me and I'm not sure if it is just because it is new. I may also be over thinking the whole thing.

Answer 1

I think I'd program this by writing a couple of the "derived" classes, but without worrying about the base class. I would then refactor to remove the duplication. That way, I wouldn't be speculating about the base class before I had working derived classes.

Among other things, I would make sure that I had working code for the consumers of all of these classes, in order to make sure of how much the consumers need to know about the data being consumed. For instance, do the consumers need to know if the load is complete? Do they need to find a "good point" at which to display data that may still be loading? If the consumers turn out not to need any of this information, then the loading process becomes an implementation detail of the "derived" classes, and not something they need to expose publicly.