What are the pitfalls of using .NET RIA Services in Silverlight?

FOLLOWING MY PREVIOUS ANSWER HERE THE DISADVANTAGES OF RIA SERVICES: On the other end the disadvantage of ria services is its lack of flexibility. Mainly it is like a tube that connect a class on the server side with its client side representative in such a way you operate on the client side class like you were operating directly on the server side class. If the way this "tube" his handled is ok for your application, you get a lot of services fro free (without writing any code...). However, there are limitations that one cannot remove specifically:

1) You have not the same freedom in defining behavior, attribute etc. to modify the way the Web service behaves. For instance you cannot define a distributed transaction involving more than one web service. It is difficult to add new endpoints....You have to write code....not simply modifying a configuration file.

2) You can only define one Insert/one update/one get methods for each class. If you apply filtering to the client side query via LINQ it is applied only on the client, i.e. all data are downloaded from server and then filtered on the client. On the contrary if you use a WCF data services based on OData and you define a query on the client side. THIS QUERY IS TRANSLATED INTO A REST QUERY (a query encoded in the URL of the request) THEREFORE ONLY THE DATA YOU REQUIRE WITH YOUR FILTER ARE ACTUALLY DOWNLOADED FROM THE SERVER. For more information on WCF data service see here.

3) By contrast with WCF Data Services you have no Validation service offered as with Ria service. However you can continue using data annotatios with the help of my Validation Toolkit for WPF & Silverlight, that is available for free here

Ria services and rest services offers a quite similar access to server side classes that often are entity framework classes(but not necessarely...as several programmers appears to belive). The main advantage of Ria Services is that they handles Validation by using Data Annotations on server-side classes and do it in a smart way: they automatically generate client side-classes with the same data-annotations and validate them by implementing automatically INotifyDataError on the client-side class. If one uses custom attributes and put the.shared.cs (or .vb) extension those attribute definitions are copied in the silverlight client and used in the client-side validation, otherwise they are used only to perform server-side validation......for more information pls see my blog post

here

I have been using SL4 + EF for our enterprise development and I found it, it is hard to develop with EF if you go with the default out of box development model. What I mean by that is, any screen you develop, for the data you use EF with a table/view then very quickly the your model get blotted. After adding 20 new pages with 6 to 10 tables/views now it is very difficult to add entities in the edmx. I personally do not like the blotting. If you see some of the questions I have asked and based on the answers it seems for enterprise level development do not use stright out of the box EF features instead, create a domain model using POCO with PI and then use that to develop your application. I have not completed one successfully yet so I do not have personal result on this. One another thing, I noticed it is not related EF per se instead SL itself. Spend some time and understand either PRISM/MEF/Caliburn and use that create your application. One of the problem I do not like in SL is testability, even though SL unit testing is there, it itself is not a good unit testing framework. Also testing EF is not breeze either. With PRISM/MEF/Caliburn not only testing is easy and also your development will be truly modular. So before you start your development, my recommendation is to look at one of the framework and instead of using EF outof box, use POCO to create your domain model and then use POCO to use it in SL. Hope this helps.