.NET RIA Services Part 1: When to Use It
I’ve started using the July 2009 preview of .NET RIA Services (which really could use a better name, btw) in my engagement and have become quite a big fan.
The first question my coworkers asked when I started telling them about it was “When should I use it instead of WCF?” Hopefully by the end of this post you (and they) will have a better understanding of the tradeoffs involved with using .NET RIA Services and why it is a great solution for a lot of data-intensive RIAs.
So, rather than creating a WCF web service to return data to fill DataGrids and other controls in Silverlight, you let RIA Services create the services for you and share the definition of the relevant classes between the client and server. It also provides lots of ways of customizing exactly what is exposed to the client.
When to Use It?
But when should we use it? Does RIA Services replace WCF?
There are certainly still times to use WCF, particularly when developing a public facing web service. But when the primary focus of your web service is to pass data from the server to a Silverlight client, then RIA Services is the way to go.
Another reason you may forgo RIA Services is if you need tight control over the communication protocol. RIA Services uses JSON to return its results, so if you have a requirement to use XML or some other format, you’ll need to use another solution. (Update: After listening to Brad Abrams on Hanselminutes, it looks like RIA Services can be customized just like WCF)
For a data-heavy Silverlight business application, though, RIA Services greatly simplifies the plumbing of connecting your back-end to the Silverlight application. In the next part, we’ll look at creating a simple RIA Services application.