Apr 09

As I’ve said before, I’ve started porting an existing project to .NET 4.0. I’ve tried using the new features .NET 4.0 introduces (ex.: code contracts). One of the objectives I had was replacing the traditional WCF service calls with RIA services. Until now, I’ve watched a couple of presentations (for instance, Nikhil’s presentation on MIX 2010) and it really seemed great.

I must say that I was a little suspicious about it because all the presentations I had seen used EF (and if you know me, you know that I’m still not ready to say goodbye to NHibernate and I do really believe in hiding/abstracting my backend behind an OO domain model). Anyway, I’ve decided to go ahead and tried to reuse my domain model in a RIA Service after reading about presentation models in the RIA Services documentation. What a bad mistake…It did cost me a day and a hald…Unfortunately, RIA Service don’t really integrate well with “real world” objects. For instance, take a look at my DTO (which I was trying to expose to the SL client):

[DataContract(Namespace = "")]
public class OcorrenciasPaginadas {
    [Key]//don’t like this, but can live with it
    public Int32 TotalElementos { get; set; }

    public IEnumerable<ResumoOcorrencia> Ocorrencias { 
get; set; } }

As you can see, I had to add annotate  the TotalElementos with the KeyAttribute (even though TotalElementos is not an ID; anyway, it seems like objects must always be annotated with a key). The worst of all is that the client proxy that is automatically generated in the client side doesn’t include the Ocorrencias property. After talking with Fredrik, he mentioned the IncludeAttribute. So,I’ve started by adding it. Unfortunately,it started complaining that the IncludeAttribute can only be used in association with the AssociationAttribute.

After reading the docs, it was really obvious that RIA Services considers each entity as a lightweight wrapper around a row of a table (that’s the only justification I can think of for making me add an Id property to ResumoOcorrencia that “points back” to the “main” OcorrenciasPaginadas object). In other words, RIA Services does some really cool things, but it’s just not for me because I’m not exposing my backend tables directly to my clients (I’m sorry, but I have a domain model which is responsible for everything and my clients only consume DTOs – which in most situations are really different from the tables that the domain uses to persist data).

I really expected much more from MS, especially because they’ve been presenting RIA Services as something which  can be used with any backend you have (if you don’t believe me, just watch any RIA Services presentation. I bet the guy that is presenting will always say something like “I’m using EF because this is quicker than building my own domain; don’t worry to much with this because you can expose any backend/model you’ve got with this wonderful technology”; this is not true, though I can confirm that if you’re using EF, then RIA Services do really rule).

Bottom line: goodbye RIA Services; Hello again “plain WCF”!

2 comments so far

  1. Ricardo Peres
    1:17 pm - 4-9-2010

    Perhaps you picked the wrong technology: maybe WCF Data Services is what you need. You can use whatever you want on the server side (NH, EF, L2SQL) and you generate POCO classes for the client side, which have no dependencies on the underlying persistence technology.

  2. luisabreu
    1:43 pm - 4-9-2010

    Hello Ricardo.

    One of the reasons I went with RIA was code reuse in the client (including basic validation). I”ve used ADO.NET Data Services in the past, but I haven”t really looked at it recently. I”ll probably do that in the next days (thanks for the tip).