A few weeks back I wrote about getting RIA services to work with POCO.  It was a long post, so long that it was 5 posts.  In the weeks since, I spent some time trying to use POCO/RIA in some work that I was doing for a client, and I started to develop some strong feelings about why bother with all of this extra work to just get things to work with RIA instead of just using WCF/Data Contracts/DTOs.  I'm still trying to be able to articulate these feelings, but figure I'll give it a shot right now.

First, it was a lot of work to get the POCO to work with RIA, at least compared to just creating a class that is annotated with DataContact/DataMember attributes.  The former took me 5 posts just to describe how it works.  The latter takes maybe a minute to build an end to end solution.

But that's not all.

Second, a lot of what RIA (excuse me WCF RIA) does is autogenerate code to do different things, such as generating client side objects that know how to track changes and do automatic validation.  I'm left to wonder about the former, but do by that the automatic validation code is useful, but I'm not sure its worth the effort getting POCO to work over using validation libraries such as EL. 

The issue with tracking changes I think is the sticking point, as I don't see what value there is in POCO, as it is inherently tied to using entities on the server side (read Entity Framework).  Without the mapping back to entities in the client side, is it adding any value?  I don't see that it is.

This also leads to the generation of service methods for which I can see as nothing but CRUD operations.  Again in a POCO world, is CRUD really necessary?  If I'm not using a database, and not modelling my objects off of entities generated from the database, do I really need CRUD methods auto generated by convention? And to be honest, it was really hard to just get a single POCO object returned with RIA.

So what I think this boils down to is without a database, and then additionally without EF, I don't see the advantage.

And now one more kicker.  The system I was building wanted to try and use RIA, but we were not connecting to a database, so hence the POCO route.  Instead of a database, we are connecting with a backend system via EMS messages bridged over JMS into services in Oracle.  This throws this whole thing into the world of asyncronous messaging.  WCF RIA services are inherently tied to syncronous operations, since they pretty much are generated to do syncronous communications to the database and return the result.  The EMS method we looked at had to be asyncronous (it's the nature of the environment I'm working in, not that EMS can't be syncronous - the back end Oracle app could not do this syncronously). 

So, the method to get objects would need to either block waiting to a response message on EMS, or return directly without any data.  In the latter case, there is really no use for RIA; why do all this magic if I can't get the data to be managed during the RIA services call?  Well, none that I can see.  In the case of blocking waiting for a response, sure I can program that, but it is going to inherently reduce scalability of the solution.  And it kind of defeats one of the things I really like about Silverlight - the asyncronous nature of calls to the client.  The Silverlight client will still do the call asyncronously which is great, but with my having to program syncronous blocks on the server it just seems to defeat the purpose.  I would rather go totally asyncronous and gain all the scalability possible, even at the expense of having to use callbacks from the server to the silverlight client for when response messages arrive back on EMS.

So, I guess this would lead to some rules about when to use / not use WCF RIA.  I'll take a try at them...

When not to use:

• You are not using a database.
• You need asyncronous communications with a third tier
• You are using something other than Silvelright for a client

When to use:

• You don't have a database, or are doing async communications with a third tier, but feel the automatic generation and use of validation rules is worth the effort
• You are building forms-like CRUD apps against your database model

I also have concerns about how portable this is to non-Silverlight clients.  For example, I can't use the RIA objects in WPF, and I wonder how this would integrate to web or AJAX clients; sure the classes can't be used, but can you use the web services that are exposed?  My guess (as I haven't tried it yet) is that you can't, at least easily.

I'd really like to hear your comments on this.  Every time I look at RIA services I really want to like it, and I'd like to be able to feel like it has broader value, so please let me know your experiences.