When I first looked at WCF RIA Services, I have to admit I was a bit mystified at what I was seeing.  Compared to a traditional n-tier application, where there is a clean separation and only contract and schema are shared , it seemed like a  throw back to client-server application design, where both ends are tightly coupled.  However, after authoring a module on WCF RIA Services for my Exploring .NET course at DevelopMentor, I gained a much better understanding of how it works under the covers and can better appreciate how RIA Services reduces the inherent complexity of n-tier development by offering features, such as end-to-end data validation, that would be difficult to implement on your own.

Some ambiguity may have been created by positioning RIA Services as a Silverlight-based technology.  As far as I can tell, there’s nothing intrinsic to RIA Services that ties it to Silverlight.  Presently, the way you create a RIA services client is by “linking” a Silverlight project to an ASP.NET web project.  But this just creates a custom MSBuild task that reflects over types defined in the web project and generates code in the linked client project.

There’s nothing to stop the RIA Services team from opening that up to non-Silverlight clients.  in fact, there’s word that they are already moving in that direction by allowing you to use T4 templates to generate client entities and placing those entities in a separate class library.

I think another source of ambiguity may rise from the description of RIA Services as “RAD for RIA,” with a RIA application being a single logical application that blurs the line separating the presentation and service layers.  While I can appreciate many of the productivity benefits provided by RIA Services, I wince at the comparison to classic two-tier ASP.NET application architecture because in fact RIA Services is still just a WCF Service (I tend to drop the WCF just to save on typing).  There is a client (Silverlight now, but WPF in the future), a middle tier (the domain service), and a back end (entity data model, or custom DAL).

Then there seems to be a bit of magic happening to support features like query composability, change-tracking and batch updates, attributes for presentation and data validation, shared code and async support.  In reality there’s no magic, just the framework providing features that you would otherwise have to build yourself.  The problem is the absence of a decent white paper on RIA Services that explains all of this in detail.  There is a white paper, but it’s just a brief high-level overview.  You’ll get much more information from the chapter on RIA Services in Silverlight 4 in Action by Pete Brown, and from an assortment of blog posts.

Since this post is already getting rather long, I will follow it up with a few more posts detailing various aspects of WCF RIA Services.

1. WCF Service endpoints: binary, soap, odata, json
2. DomainService operations (invoke, update, CRUD)
3. DomainContext methods and async operations
4. Query composability with IQueryable
5. Entity metadata (presentation, composition, loading, validation)
6. Data validation (per property, cross property, server, async)
7. Security (authentication, authorization)

In the meantime, I welcome comments on what I’ve said so far.  I think RIA Services offers a great deal of features that will make your life easier when developing n-tier applications using Silverlight and (in the future) WPF.  I would even venture to say you should seriously consider using it for Silverlight business applications, in concert with basic WCF SOAP and Data Services (more on that in my next post).