LINQ to Bing, Silverlight and .NET RIA Services

Accessing Bing through a Server Proxy
I'll first cover the proxy-through-your-server solution. In this case, I'll use the LINQ to Bing API within a DomainService that runs on the server, and use the regular .NET RIA Services tooling to get a DomainContext generated into the client that I can program against from within my presentation tier. Here is my very basic DomainService class that encapsulates the search functionality needed in my simple application:

[EnableClientAccess]
public class SearchService : DomainService {

    private BingContext CreateContext() {
        string appKey = ConfigurationManager.AppSettings["BingAppKey"];
        return new BingContext(appKey);
    }

    public IQueryable<ImageSearchResult> SearchImages(string query) {
        BingContext context = CreateContext();
        return from i in context.Images.SafeResults()
               where i.Query == query
               select i;
    }

    public IQueryable<PageSearchResult> SearchPages(string query) {
        BingContext context = CreateContext();
        return from p in context.Pages.SafeResults()
               where p.Query == query
               select p;
    }
}

Some interesting observations:

• SearchService derives directly from DomainService. It doesn't depend on your traditional DALs such as LINQ to SQL or Entity Framework. The domain service pattern doesn't prescribe a particular DAL, and in fact, we have a fundamental architectural tenet to not invent or require a particular data access technology.
• Also, I can use the BLinq API as-is and directly from within my DomainService (just like I had in my console app in the previous post). No DAL abstractions are involved or required, and this is another fundamental architectural tenet.
• The query methods return an IQueryable, rather than a list of results. This allows further query composition by the caller. Specifically it allows the client to pass in Skip/Take LINQ expressions that get remoted to the server and subsequently all the way to the Bing service when the BingQueryProvider translates the final query into a URI. This allows paging over the results. The value of this is as the developer of SearchService, I didn't have to code for every permutation of query parameters (which can become painful in more complex apps).
• I can of course introduce additional query methods, that for example take additional parameters, or perform server-side caching or aggregation of data from multiple sources of data, or filtering of data on the server, log queries, save recent queries for the current user etc. etc. This is the value of domain services, and having a place to put your code. You can do what makes sense for your application. For the demo, these two simple ones that ensure strict results will suffice.

Based on this I get the following code generated on the client (look at SearchApp.Web.g.cs after clicking on Show All Files):

public sealed partial class ImageSearchResult : Entity {
    ...
}

public sealed partial class PageSearchResult : Entity {
    ...
}

public sealed partial class SearchContext : DomainContext {

    public SearchContext() : 
        this(new HttpDomainClient(new Uri("DataService.axd/SearchApp-Services-SearchService/",
                                          System.UriKind.Relative))) {
    }

    public EntityList<ImageSearchResult> ImageSearchResults {
        get { ... }
    }
        
    public EntityList<PageSearchResult> PageSearchResults {
        get { ... }
    }
        
    public EntityQuery<ImageSearchResult> SearchImagesQuery(string query) {
        ...
    }
        
    public EntityQuery<PageSearchResult> SearchPagesQuery(string query) {
        ...
    }
}

I can program against this programmatically. For example, I could write the following code in my code-behind:

private void LoadData() {
    SearchContext context = new SearchContext();
    pagesList.ItemsSource = context.PageSearchResults;

    EntityQuery<PageSearchResults> query =
        context.SearchPagesQuery("nikhil");
    context.Load(query);
}

In the application, I used a DomainDataSource control, rather than the code above. The declarative datasource model is nice when I don't have any additional logic to add on the presentation tier. I might as well let it handle UI parameter changes, loading data asynchronously, managing loaded data etc.

<TextBox Grid.Row="2" x:Name="searchTextBox" />

<ria:DomainDataSource x:Name="pagesDataSource"
  DomainContext="{StaticResource searchContext}"
  QueryName="SearchPagesQuery">
  <ria:DomainDataSource.QueryParameters>
    <riadata:ControlParameter ParameterName="query"
      ControlName="searchTextBox" RefreshEventName="TextChanged" />
  </ria:DomainDataSource.QueryParameters>
</ria:DomainDataSource>

<ItemsControl x:Name="pagesList" ItemsSource="{Binding ElementName=pagesDataSource, Path=Data}">
  <ItemsControl.ItemTemplate>
    <DataTemplate>
      <StackPanel>
        <HyperlinkButton Content="{Binding Title}" NavigateUri="{Binding Uri}" TargetName="_blank" />
        <TextBlock Text="{Binding Description}" />
        <TextBlock Text="{Binding DisplayUrl}" />
      </StackPanel>
    </DataTemplate>
  </ItemsControl.ItemTemplate>
</ItemsControl>

Each time the text in the search TextBox changes, the DataSource formulates an EntityQuery and passes it on to its SearchContext to load results. These results get rendered in the bound ItemsControl. This is almost identical to the snippet of code I wrote in the imperative variant I started with.

Above is the diagram of the different layers when using server-side proxying. The gray boxes, i.e. the web service and the corresponding HttpDomainClient are plumbing. The web service box is responsible for exposing your application logic, while the DomainContext is responsible for surfacing your data to the rest of the application by working against the associated DomainClient. It will be interesting to compare this with the corresponding diagram for direct access to Bing from the client, which follows next.

Accessing Bing directly from the Client
As you probably observed in the code above, the server doesn't do anything particularly interesting, other than proxying requests. In many cases, a proxy is necessary, when a service doesn't support cross-domain access, or you've got sensitive information to access the service that you don't want to ship to the client. Bing however is a reasonable candidate for accessing directly from the client.

While I want let go of my server-side proxy, and make requests to Bing directly from my Silverlight code, I'd still like to use the EntityList, EntityQuery and DomainContext-based programming model on the client. To make this possible, I've implemented a BingDomainContext class the Silverlight version of BLinq, and a BingDomainClient which encapsulates logic for making Bing API requests. Your Silverlight application can derive from that instead of using generated code based on some server-side code.

public class SearchContext : BingDomainContext {

    public SearchContext()
        : base(appKey) {
    }
}

BingDomainContext from the BLinq framework has the following OM:

public abstract class BingDomainContext : DomainContext {

    protected BingDomainContext(BingDomainClient domainClient)
        : base(domainClient) {
    }

    protected BingDomainContext(string appKey)
        : this(new BingDomainClient(appKey)) {
    }

    public EntityList<ImageSearchResult> ImageSearchResults {
        get { ... }
    }

    public EntityList<PageSearchResult> PageSearchResults {
        get { ... }
    }

    public EntityQuery<ImageSearchResult> SearchImagesQuery(string query) {
        ...
    }

    // Other image query methods...

    public EntityQuery<PageSearchResult> SearchPagesQuery(string query) {
        ...
    }

    // Other page query methods...
}

Interesting observations:

• SearchContext derives from BingDomainContext, which provides identical set of EntityLists and query methods as we saw before in the first approach.
• BingDomainContext uses a BingDomainClient instead of the regular HttpDomainClient you get by default as shown in bold. This is the key. BingDomainClient encapsulates the logic to work with the Bing APIs and plugs in under the DomainContext. So the programming model on top remains intact, but the network communication layer has been completely swapped.

The public surface area, and programming model exposed by SearchContext that uses BingDomainContext/BingDomainClient is 100% identical. The rest of the application remains completely unchanged. For example, DomainDataSource doesn't know anything about the fact that the networking layer has changed. The DataPager controls compose Skip/Take expressions into the LINQ query as before, and it all gets translated into Bing search URIs, this time on the client, rather than on the server. Here is the corresponding diagram, that shows how the client exists without any server-side counterparts of typical .NET RIA Services applications:

Hopefully this shows how easy it is to incorporate Bing into your Silverlight applications using .NET RIA Services, regardless of which approach, using server-side proxying or direct client access, makes sense for your application. All of the framework code and both sample applications are available for download. As before you'll need to visit the Bing developer page, and retrieve an application key to use on your end when running the code. You'll also need the latest [http://code.msdn.microsoft.com/riaservices] CTP of .NET RIA Services.

Some technical details on DomainClient...
I had previously described the DomainClient extensibility point in my post on unit testing client-side code by mocking out the server via a MockDomainClient that uses an in-memory store rather than making requests to a service. Essentially as I described in that post, the DomainClient represents a general proxy for services whose API can be abstracted as a set of Query operations, a SubmitChanges operation, and a set of Invoke operations.

You can derive from DomainClient and plug it in underneath a DomainContext to take over the low-level details of working against a service, while keeping the higher level programming model intact. I'd recommend checking out the code if you're interested in plugging in your own service or back-end. If you are doing this or interested in this, I'd love to hear about it! I am personally interested in writing a TwitterDomainClient...

From a layering perspective, here are the different bits within the .NET RIA Services client framework and their purposes:

• Entity, EntityList, EntityContainer - these represent the client-side data model. You've got your “record” instance, a list of instances, and a set of lists. Roughly speaking these map to DataRow, DataTable and DataSet if you're familiar with those. In fact, they can be used independently as a subsystem that allows you to work with and manage a set of objects, potentially related via associations, tracked for changes, and identity managed.
• DomainContext - the programming model that provides a wrapper over the Entity subsystem to provide semantics around loading of data via queries, and submitting of changes in the form of a change set.
• DomainClient - the layer that handles serialization, protocol and the specific service to communicate with. It translates the abstract notion of query, submit and invoke to the specific APIs exposed by some service.

Hopefully this shows how the .NET RIA Services client framework is flexible and makes its base services and programming model applicable in a variety of contexts and services, even though we've specifically done a bunch of work to make the end-to-end scenario involving your client talking to its own server half super simple.