Silverlight 4 + WCF RIA - Data Service Design Best Practices

Hey all. I realize this is a rather long question, but I'd really appreciate any help from anyone experienced with RIA services. Thanks!

I'm working on a Silverlight 4 app that views data from the server. I'm relatively inexperienced with RIA Services, so have been working through the tasks of getting the data I need down to the client, but every new piece I add to the puzzle seems to be more and more problematic. I feel like I'm missing some basic concepts here, and it seems like I'm just 'hacking' pieces on, in time-consuming ways, each one breaking the previous ones as I try to add them. I'd love to get the feedback of developers experienced with RIA services, to figure out the intended way to do what I'm trying to do. Let me lay out what I'm trying to do:

First, the data. The source of this data is a variety of sources, primarily created by a shared library which reads data from our database, and exposes it as POCOs (Plain Old CLR Objects). I'm creating my own POCOs to represent the different types of data I need to pass between server and client.

DataA - This app is for viewing a certain type of data, lets call DataA, in near-realtime. Every 3 minutes, the client should pull data down from the server, of all the new DataA since the last time it requested data.

DataB - Users can view the DataA objects in the app, and may select one of them from the list, which displays additional details about that DataA. I'm bringing these extra details down from the server as DataB.

DataC - One of the things that DataB contains is a history of a couple important values over time. I'm calling each data point of this history a DataC object, and each DataB object contains many DataCs.

The Data Model - On the server side, I have a single DomainService:

[EnableClientAccess]
public class MyDomainService : DomainService
{
    public IEnumerable<DataA> GetDataA(DateTime? startDate)
    {
        /*Pieces together the DataAs that have been created 
        since startDate, and returns them*/
    }

    public DataB GetDataB(int dataAID)
    {
        /*Looks up the extended info for that dataAID, 
        constructs a new DataB with that DataA's data, 
        plus the extended info (with multiple DataCs in a 
        List<DataC> property on the DataB), and returns it*/
    }

    //Not exactly sure why these are here, but I think it 
    //wouldn't compile without them for some reason? The data 
    //is entirely read-only, so I don't need to update.
    public void UpdateDataA(DataA dataA)
    {
        throw new NotSupportedException();
    }
    public void UpdateDataB(DataB dataB)
    {
        throw new NotSupportedException();
    }
}

The classes for DataA/B/C look like this:

[KnownType(typeof(DataB))]
public partial class DataA
{
    [Key]
    [DataMember]
    public int DataAID { get; set; }
    [DataMember]
    public decimal MyDecimalA { get; set; }
    [DataMember]
    public string MyStringA { get; set; }
    [DataMember]
    public DataTime MyDateTimeA { get; set; }
}

public partial class DataB : DataA
{
    [Key]
    [DataMember]
    public int DataAID { get; set; }
    [DataMember]
    public decimal MyDecimalB { get; set; }
    [DataMember]
    public string MyStringB { get; set; }
    [Include] //I don't know which of these, if any, I need?
    [Composition]
    [Association("DataAToC","DataAID","DataAID")]
    public List<DataC> DataCs { get; set; }
}

public partial class DataC
{
    [Key]
    [DataMember]
    public int DataAID { get; set; }
    [Key]
    [DataMember]
    public DateTime Timestamp { get; set; }
    [Da开发者_JS百科taMember]
    public decimal MyHistoricDecimal { get; set; }
}

I guess a big question I have here is... Should I be using Entities instead of POCOs? Are my classes constructed correctly to be able to pass the data down correctly? Should I be using Invoke methods instead of Query (Get) methods on the DomainService?

On the client side, I'm having a number of issues. Surprisingly, one of my biggest ones has been threading. I didn't expect there to be so many threading issues with MyDomainContext. What I've learned is that you only seem to be able to create MyDomainContextObjects on the UI thread, all of the queries you can make are done asynchronously only, and that if you try to fake doing it synchronously by blocking the calling thread until the LoadOperation finishes, you have to do so on a background thread, since it uses the UI thread to make the query. So here's what I've got so far.

The app should display a stream of the DataA objects, spreading each 3min chunk of them over the next 3min (so they end up displayed 3min after the occurred, looking like a continuous stream, but only have to be downloaded in 3min bursts). To do this, the main form initializes, creates a private MyDomainContext, and starts up a background worker, which continuously loops in a while(true). On each loop, it checks if it has any DataAs left over to display. If so, it displays that Data, and Thread.Sleep()s until the next DataA is scheduled to be displayed. If it's out of data, it queries for more, using the following methods:

public DataA[] GetDataAs(DateTime? startDate)
{
    _loadOperationGetDataACompletion = new AutoResetEvent(false);
    LoadOperation<DataA> loadOperationGetDataA = null;

    loadOperationGetDataA = 
        _context.Load(_context.GetDataAQuery(startDate),
        System.ServiceModel.DomainServices.Client.LoadBehavior.RefreshCurrent, false);
    loadOperationGetDataA.Completed += new
        EventHandler(loadOperationGetDataA_Completed);

    _loadOperationGetDataACompletion.WaitOne();
    List<DataA> dataAs = new List<DataA>();
    foreach (var dataA in loadOperationGetDataA.Entities)
        dataAs.Add(dataA);

    return dataAs.ToArray();
}

private static AutoResetEvent _loadOperationGetDataACompletion;
private static void loadOperationGetDataA_Completed(object sender, EventArgs e)
{
    _loadOperationGetDataACompletion.Set();
}

Seems kind of clunky trying to force it into being synchronous, but since this already is on a background thread, I think this is OK? So far, everything actually works, as much of a hack as it seems like it may be. It's important to note that if I try to run that code on the UI thread, it locks, because it waits on the WaitOne() forever, locking the thread, so it can't make the Load request to the server.

So once the data is displayed, users can click on one as it goes by to fill a details pane with the full DataB data about that object. To do that, I have the the details pane user control subscribing to a selection event I have setup, which gets fired when the selection changes (on the UI thread). I use a similar technique there, to get the DataB object:

void SelectionService_SelectedDataAChanged(object sender, EventArgs e)
{
    DataA dataA = /*Get the selected DataA*/;

    MyDomainContext context = new MyDomainContext();
    var loadOperationGetDataB = 
        context.Load(context.GetDataBQuery(dataA.DataAID),
        System.ServiceModel.DomainServices.Client.LoadBehavior.RefreshCurrent, false);
    loadOperationGetDataB.Completed += new
        EventHandler(loadOperationGetDataB_Completed);          
}

private void loadOperationGetDataB_Completed(object sender, EventArgs e)
{
    this.DataContext = 
        ((LoadOperation<DataB>)sender).Entities.SingleOrDefault();  
}

Again, it seems kinda hacky, but it works... except on the DataB that it loads, the DataCs list is empty. I've tried all kinds of things there, and I don't see what I'm doing wrong to allow the DataCs to come down with the DataB. I'm about ready to make a 3rd query for the DataCs, but that's screaming even more hackiness to me.

It really feels like I'm fighting against the grain here, like I'm doing this in an entirely unintended way. If anyone could offer any assistance, and point out what I'm doing wrong here, I'd very much appreciate it!

Thanks!

I have to say it does seem a bit overly complex.

If you use the entity framework (which with version 4 can generate POCO's if you need) and Ria /LINQ You can do all of that implicitly using lazy loading, 'expand' statements and table per type inheritance.