What is .NET RIA Services and why should you care?

At MIX 2009 this year, there were a lot of really good sessions (and a couple of really bad ones, too). Microsoft unveiled a lot of really cool stuff, including Silverlight 3 and new CTPs of various Azure and Mesh products and even a new CTP of the Velocity distributed cache and there was even a preview of ASP.NET 4.0.

One of the bits of technology that didn't seem to get near enough attention relative to how valuable it is was .NET RIA Services. .NET RIA Services is a set of tools and libraries that make the life of a RIA (Rich Internet Application) developer much easier. Basically if you are writing a Silverlight application that will ever need to talk to your server, then .NET RIA Services is your new best friend. No, I'm not sugar coating it, it's that useful.

This is a huge oversimplification, but basically here's how it works: You expose some entities on the server using RIA Services. These entities can be LINQ to SQL, LINQ to Entities, or your own custom data (such as data you obtain by talking to another tier or more services). Once these entities are exposed, when you build your solution a client proxy is auto-generated and placed into your Silverlight application project. This allows you to use LINQ queries, maintain local state in Silverlight, manage dirty entities, perform batch updates, perform transactions, and even access authentication, authorization, and profiles all while hiding the underlying HTTP communication.

If you stop to think about this for a minute, this is bigger than it seems. The main reason is because typically every time you expose data via Web Services to a client, you have a server-side model and a client-side model. Anytime you change the server model it breaks the client model and you end up with this little anti-corruption layer on the client to allow you to communicate cleanly. People often get around this problem by creating a single shared library that contains the model... but this has other problems too, including enforcing too much tight coupling between the client and the server.

Having the client proxies generated in this manner means that you can have your server-side entity model and you can have a client-side local-state model that is _bindable_ (it publishes change events!) enables all sorts of possibilities. In addition, you can decorate the server model with validation attributes which will also be enforced in the client proxies, giving your GUI the capability of displaying rich validation messages while still maintaining server integrity by preventing "bad" commits.

Again, I'm horribly oversimplifying things (I will be posting some code walkthroughs later), but having this robust model to synchronize server and client models and share code between tiers saves the developer a flaming truckload of work. And because .NET RIA services embraces LINQ and the concept of entities, you can even supply a full LINQ query on the client side which will be serialized out, converted into URL parameters, and then invoked by the server. Try doing that with your own home-brewed service communication library.

The bottom line is that if you are writing a Silverlight application that will ever require reading or writing data on your server, then you absolutely need to check out .NET RIA Services.

tags: silverlight  dotnet  ria  riaservices  

links: digg this    del.icio.us    technorati    reddit