If you're a regular reader of my blog, you'll probably remember my pithy blog post where I stated that "It all depends..." to the question "Which Data Access Should I Use for Silverlight 3?" The reality is that much like the similar question I am confronted with at user groups for the past decade ("What data access should I use in my .NET app?"). The reasons for picking a strategy are wide and varied so I will not try to analyze all possible outcomes, but I think the different strategies need to be explained better.
The three major candidates in Silverlight 3 are Web Services (WCF/ASMX), ADO.NET Data Services and RIA Services. In any situation, any of these will work. But they are suited to different styles and requirements. Here's the abridged differences between the stacks:
- Web Services: Interface-based Data Access
- ADO.NET Data Services: LINQ-based Data Access with change management
- RIA Services: Interface-based Data Access with change management
Let's dive deeper into explaining these differences and why that might matter.
Web Services
Using web services is the tried and true method for communicating across the firewall. This pattern is well known and reliable. In general this requires you specify an interface for the CRUD operations as separate operations on a web service then dutifully call them in your Silverlight code.
Reasons to Use: Any existing investment in web services can be a great reason to use them (whether in code or skillset). Also, web services are often used in cases where a project wants a very close control over the flow from the application to the database.
Reasons to Avoid: With web services you end up having to keep track of the changes yourself and know what services to call with updates. Any need for batching or transactional support gets cumbersome and code-intensive.
ADO.NET Data Services is a simple REST-based facility for data access. It relies on the HTTP stack to help define the interface. GET calls become Reads, POST becomes Updates and so on. It uses ATOM or JSON for its serialization format so it is consumable by a variety of clients.
Underneath its covers it takes this URI based API and converts it into a LINQ call for GETs and to API calls to the provider for inserts, updates and deletes. That means that ADO.NET is a thin layer who's purpose is to translate the URI model to data access code. But its better than that...
The real power of ADO.NET Data Services for Silverlight is the inclusion of the Client Library. This client library allows you to issue LINQ queries defined in the client and executed on the server. While the LINQ syntax is somewhat limited when compared to the server, it fulfills the 80% case and ADO.NET Data Services allows you to add operations to fill in the rest when necessary. In addition, the client library includes a powerful data context class that can monitor changes and issue changes in batches with transactional support.
Exposing your data access with ADO.NET Data Services is about exposing queryable end-points instead of defining an interface. This is what makes is unique. For example, we can query our service using a LINQ Query like so:
// Silverlight Code
// Create the query using LINQ
var qry = (from g in ds.Games
where g.Price < 50m
orderby g.Name
select g) as DataServiceQuery<Game>;
// Execute the Query
// (This part is getting cleaner in ADO.NET Data Services v1.5)
qry.BeginExecute(new AsyncCallback(r =>
{
games2.ItemsSource = qry.EndExecute(r).ToList();
games2.DisplayMemberPath = "Name";
}), null);
Reasons to Use: Want a simple, secure model where the developers can define the queries they need in code instead of changing the interface as the needs change. The ADO.NET Data Services' client library makes the amount of code you write on the client small as it becomes LINQ calls and working with the context class.
Reasons to Avoid: When you want tight control over the interface to your data access and do not want developers issuing LINQ queries directly from the client code.
RIA Services
As the new kid on the block, RIA Services has a lot to offer. RIA Services is based on the idea of creating a data access API on the server and at the same time creating the client code in Silverlight (and other platforms in the future). Its focused on sharing code between the client and the server including validation logic. In addition, while it allows you to create a set interface, it also provides a context object which can monitor changes on the client and batch those changes back to the server. In some ways RIA Services is like a hybrid of Web Services and ADO.NET Data Services.
Because RIA Services is based on a server-side query defined in its interface, on the client we call the query by calling the call on the interface:
// Silverlight Code
// The context object that tracks changes
XBoxGamesContext ctx = new XBoxGamesContext();
// Our RIA Query, really a call to an interface
var qry = ctx.GetGamesByGenreQuery("Shooter");
// Bind the data
theList.ItemsSource = ctx.Load<Game>(qry).AllEntities;
While in ADO.NET Data Services you are issuing LINQ queries, RIA Services also allow you to add LINQ constraints to the query endpoints. For example instead of just creating a query by calling the interface, you can add LINQ expressions to the endpoint like so:
var riaQry = ctx.GetGamesQuery()
.Where(g => g.Price < 50m)
.OrderBy(g => g.Name);
LoadOperation<Game> op =
ctx.Load<Game>(riaQry);
Reasons to Use: RIA Services is a good choice if you expect to develop a straightforward application minimum number of tiers. It works best in Rapid Application development scenarios versus large architected applications. RIA Services does support a mix between the interface based from Web Servics and and LINQ based querying that is supported by ADO.NET Data Services.
Reasons to Avoid: RIA Services leverages a lot of magic code generation to make it work and that is harder to debug than it should be. Integration with large enterprises is possible, its not as easy it as it should be.
"So Which Would You Suggest?"
While I paint this picture of data access in Silverlight with a broad brush, I still get the question to suggest one over the other. The fact remains that there isn't a right/wrong answer here. A lot of it depends on the environment, project and skillset of the developers. So, no...I won't tell you what I suggest because I don't know the requirements and environment you work in. That's why they pay you the big bucks to be a developer, right?
