redoing object model construction to fit with asynchronous data fetching

I have a modeled a set of objects that correspond with some real world concepts.

TradeDrug, GenericDrug, TradePackage, DrugForm

Underlying the simple object model I am trying to provide is a complex medical terminology that uses numeric codes to represent relationships and concepts, all accessible via a REST service - I am trying to hide away some of that complexity with an object wrapper.

To give a concrete example

I can call

TradeDrug d = Searcher.FindTradeDrug("Zoloft")    or
TradeDrug d = new TradeDrug(34)  

where 34 might be the code for Zoloft. This will consult a remote server to find out some details about Zoloft. I might then call

GenericDrug generic = d.EquivalentGeneric()
System.Out.WriteLine(generic.ActiveIngredient().Name)

in order to get back the generic drug sertraline as an object (again via a background REST call to the remote server that has all these drug details), and then perhaps find its ingredient.

This model works fine and is being used in some applications that involve data processing.

Recently however I wanted to do a silverlight application that used and displayed these objects. The silverlight environment only allows asynchronous REST/web service calls. I have no 开发者_如何学JAVAproblems with how to make the asychhronous calls - but I am having trouble with what the design should be for my object construction.

Currently the constructors for my objects do some REST calls sychronously.

 public TradeDrug(int code)
 {
     form = restclient.FetchForm(code)
     name = restclient.FetchName(code)
     etc..
 }

If I have to use async 'events' or 'actions' in order to use the Silverlight web client (I know silverlight can be forced to be a synchronous client but I am interested in asychronous approaches), does anyone have an guidance or best practice for how to structure my objects.

I can pass in an action callback to the constructor

 public TradeDrug(int code, Action<TradeDrug> constructCompleted)
 {

 }

but this then allows the user to have a TradeDrug object instance before what I want to construct is actually finished. It also doesn't support an 'event' async pattern because the object doesn't exist to add the event to until it is constructed.

Extending that approach might be a factory object that itself has an asynchronous interface to objects

 factory.GetTradeDrugAsync(code, completedaction)

or with a GetTradeDrugCompleted event?

Does anyone have any recommendations? Does anyone know how the new Reactive framework might fit in with any solution?

I would ditch the public constructors and go with async factory methods. It need not be a separate factory object, it could just be static methods on TradeDrug itself, something like:

public static void LoadByIdAsync(int id) { ... }
public static void LoadByIdAsync(int id, object userState) { ... }
public static event LoadByIdCompletedEventHandler LoadByIdCompleted;

The event-based async pattern is described here: http://msdn.microsoft.com/en-us/library/wewwczdw.aspx