Asynchronous Repository for Silverlight Application

Question

I'm familiar with the standard repository, which has an interface resembling:

public interface IRepository<T>
    {

         IEnumerable<T> All();

         T GetByID(int id);

         //etc...

    }

My problem involves attempting to implement this pattern within Silverlight which restricts remote data access to async calls (which effectively removes the concept of a return value from the interface's methods) How would one go about creating an IAsyncRepository and how would databinding to a control's ItemSource occur after a returned call?

Answer 1

If you want to use a repository pattern with Silverlight, I think the best approach is to pass in a callback method of some sort to every method, which is then called by the repository when the async call finishes. You can pass the returned object in the callback function, which is when you can setup the data-binding.

The code below is an example of how this works. It's not using the standard repository pattern, but I think you can see how it could be modified appropriately:

    public void CreatedNamedRoom(string ownerUserId, string roomName, Action<Exception, Room> callback)
    {
        notificationClient.CreateNamedRoomAsync(ownerUserId, roomName, callback));
    }

    void notificationClient_CreateNamedRoomCompleted(object sender, CreateNamedRoomCompletedEventArgs e)
    {
        var callback = e.UserState as Action<Exception, Room>;
        if (callback != null)
        {
            callback(e.Error, e.Result);
        }
    }

And then you use it something like this:

    roomData.CreatedNamedRoom(userId, roomName, (error1, room) =>
    {
        if (error1 == null)
        {
            // Setup your databinding here...
            this.Room = room;
        }
    });

Effectively, the repository becomes a wrapper for the annoying event-driven async WCF proxy methods that MS makes you use. I generally find callbacks to be a lot easier to work with than events, since you don't always know what triggered the event, and maintaining the state appropriately is a PITA. But if you wrap the events with a layer that you can use with callbacks (the Action<> bit above), maintaining the appropriate state is a lot easier.

I should also note that generic repositories probably aren't going to work well with Silverlight, assuming that you're using something like WCF on the back-end, since SOAP et al don't support generics very well. A better approach is to use the repository as an infrastructure contract, as described here. It's better architecturally, and it works better with Silverlight/WCF.