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

Question

Silverlight can use WCF, Web Services, REST based services, .NET RIA Services, but it seems like Silverlight and .NET RIA Services are preferred most.

I want to know if there are any common issues [which can be a show stopper if one goes ahead with this combo] that you have seen in practical implementation of SL with .NET RIA Services.

Thanks, Rahul

Suited

Answer 1

Working with metadata (and writing it by yourself) is really pain in the ass. Especially when you need to update your model. RIA tutorial applications look quite well on a small database but working with a model consisting of dozens of entites, you'll spend more time updating metadata than programming the application itself. This is also connected with definition of validation and all the validation and description messages on properties from resources. But we have created some T4 templates so it all gets generated automatically.

On the other hand, we're using RIA on two projects and I must say it's the best we can get. We had some troubles with validation but it can be solved (validating before checking whether the property value has changed). And once you are aware of memory management with RIA (you don't want to load the whole databse into memory on client etc.), it can be used in real life.

Unfortunately, there is no silver bullet, so if you, for example, plan other clients than your SL app to connect to the server, you should probably watch somewhere else (WCP Data Services, maybe?). Or if you don't want to update data from your client, I see RIA as overkill.

Grandmamma

Thanks gius. That helps. But currently I am trying to find an answer which tells me what all RIA can't do at all [or can do with a lot of headache and extra manipulations]. The way I see it, updating metadata gives takes care of a bunch of validation for which I would have to write a lot of code to begin with. Can you please share a little more details about T4 templates? – Suited

We have created T4 templates that generate metadata (including validation and description), service (select, insert, update, delete functions), resources (validation strings, description strings) and stored procedures (insert, update, delete) based on EF model. My colleague is cleaning the templates and preparing a blog post where they'll be published. I'll let you know as soon as it is released. – Grandmamma

About what RIA can't - think about it as EF1 vs. EF4. So it is quite hard to customize the entities behavior, you cannot use POCO, you still have to deal with DomainContext. But as I have already said - it is still probably the best way how to get data from server to your SL client app. We have created quite large application, dealt with datapaging, grids, master/details, DataForms etc. and I must say that RIA was not the show stopper. Don't take this as I am completetely satisfied, we are really looking forward to RIA2. I just would not be afraid to use it. – Grandmamma

Thanks gius. I didn't see the response till today. Seems like SO is missing a lot of emails OR notifications. – Suited

Hi Gius,Thank you so much for your assistance and advise here. I really appreciate it, and have gained a lot more confidence in RIA services now. – Suited

You're welcome. I hope this helped you. ...and if you have any further questions, just contact me or ask a SO question. – Grandmamma

Answer 2

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

Exhaustless

You're wrong about filtering with RIA services. You just have to make the filtering on the query you get from the RIA context (eg., GetCustomersQuery()) and after that pass it to domainContext.Load(). Then, whole filtering and sorting is done on the server (database server to be precise, since the query gets transferred to the underlying provider, usually EF/L2S, and by it trasnslated to SQL). – Grandmamma

Yes that is the point! The whole filtering CAN ONLY BE DECIDED ONTHE SERVER. You cannot DECIDE on the CLIENT a filter that will be applied on the server! That is you cannot say to the server ...pls give me just these... The only way to do it is by redefining the method on the server. By contrast with WCF data services ON THE CLIENT you can define a filter to be executed ON THE SEVER. This means MORE AND MORE FLEXIBILITY – Exhaustless

You can take a query that is defined on the server (includes, filtering and ordering may be there), then work with it furter on the client (add Where, OrderBy clauses), and finally pass it back to the server to load it. – Grandmamma

For example, you can do this: domainContext.Load(domainContext.GetCustomersQuery().Where(c => c.Name == "John").OrderBy(c => c.Age)); – Grandmamma

The point here is that the LINQ query will be executed on the list returned by the server! In wcf data services instead are rest based dataservices. This means that the client side query is processed as follows: 1) the linq query is parsed on the client and transformed into an url that encodes a database query 2) the query is mixed with some server side filtering server side 3) The query is translated into an sql query and executed on the DB Ria services web services have a fixed signature they are not able to receive a generic query as input as WCF rest services. – Exhaustless

I understand your point, but you're wrong - RIA services work the same way as you describe for WCF Data services. The query you pass to the Load function is definitely executed on the server. – Grandmamma

See first paragraphs of this: weblogs.asp.net/fredriknormen/archive/2009/12/30/… - it was one of the most important features of RIA services that was present even in Beta versions. – Grandmamma

I have seen the post. I have understood well the part of dynamic Linq, but I don't like it...it is like passing an sql command...instead of parameters...too risky. The risk of an exploit be used by an hacker is too high for me. However it seems that also the static Linq is executed on the server...but sincerely I don't understand how?? YOU provide the code for the get method and you are just required to return an Ienumerable?? How does Ria manipulate it to get an Entity sql query?? In the case of WCF data service there is no get method ..simply the url of the request is parsed to get the query – Exhaustless

Since the output of the get method is a generic Ienumerable the only way to filter it is by chacking each element of the Ienumerable....It is difficult for me to belive that the whole Linq query might be parsed inro an entity sql query. I continue having doubts on the efficiency of the ria services filtering...If you have further info that might help to remove my doubts pls pass it to me! – Exhaustless

I mentioned the post not because of the dynamic linq but because it was the only post that I could quickly find that explicitly mentioned that also static linq does get executed on the server. The trick is that the queries does not return IEnumerable, but IQueryable. So the linq query (Expression, to be precise) you create on the client is serialized and transfered to the server where it is executed. And by the way, the query is serialized to URL too (which, as I see it, is not always the best way). – Grandmamma

I've spoken to a member of WCF data services team about their prooject and RIA services. We agreed that these two projects are quite similar and MS is not conducting this very well. RIA pros are less coding to make it work, built-in authentication and validation. The main con is that it is a black box - you have no access to its templates (at least until v2 is out). WCF data services pros are that it is opensourced and more configurable (which is great if other clients than your SL app connect to the service). Cons are that you have to make much mmore by yourself than for RIA. – Grandmamma

I plan to write a blog post but I don't know when. Please, post here a link to your post. Thank you! – Grandmamma

Answer 3

I've been using RIA-Services for a few months and a couple of differen apps and found that I can get it to do pretty much everything I need. It saves you a LOT of time by using clever code-generation to take care of a lot of the plumbing.

It is best used if you're creating a straight forward CRUD application using EF, if that is the case then you should be fine.

If you're doing something a little different then it take a little bit more work but it still is (in my opinion) the best option for getting data to your silverlight client. There are some small annoyances but no show stoppers that I've found.

For example, I've used it with SQL Credentials (user logs into Silverlight app using their SQL login and I dynamically create connection string using the username + password). This took a little bit more work but it works fine.

I've also used it to return data to the client from Stored Procedures rather than from Entities, again this takes a bit more work but it works fine.

Hilleary

Answer 4

Ria services are created just to be used with Silverlight. They are substantially a standard "package" ready to be used by Silverlight. The advantage is that you have a lot of services without need to write code i.e.:

1. Support for data annotations
2. Support for membership provider and login
3. Support for transferring to silverlight server side generated exceptions. There is a difficulty in silverlight that make difficultthe normal error transfer of exception through FaultContract. The point is that the browser is not able to handle all error codes. Ria services solve this with a trick

All things done by Ria can be done with WCF and with other available software and in particular with Wcf data services. For instance for data annotations I found this library that do a better job than Ria services, support for membership just require activating the already existing membership endpoint of a WCF service, and finally the exception problem is easily resolved by writing a WCF behaviour. Code is available here:http://www.silverlightshow.net/Storage/10Tips.zip The point is that with Ria Service you have all this in a mouse click!. On the other side Ria Services are really difficult to customize...so if you don't like the standard solution they offer you simply can't use them

Cherish

Answer 5

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

Exhaustless

Answer 6

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.

Burrows

Hi, I am not sure you understand RIA well. EF is on the server but RIA creates its own entities on the client. What is the point of using POCO instead of EF? I just see more work with it - EF creates entities and insert/update/delete functions for you. – Grandmamma

Sorry I mis represent the RIA on that. My initial thought is the EF itself getting blotted not RIA. Sorry again :) – Burrows

RIA itself is a way how to get data from application server to the client.So it creates a service on the server and DomainContext and Entities on the client.Working with RIA from the client is quite close to EF/L2S because of the context (the difference is that all RIA actions are asynchronous).From RIA to database, it is up to you what technology you use - you just have to insert your custom code to the RIA service functions like GetCustomers, InsertCustomer, UpdateCustomer, DeleteCustomer.You also have to create metadata that tells RIA what properties pass from server entities to client. – Grandmamma

Sorry if I am going in wrong direction. But what I am trying to tell is that, when creating very large enterprise level application, we will use RIA (to achive what you said, services, domain context and entities) but instead of using simple EF to create entities, use EF POCO and create the domain knowledge classes and use them to bind it at the client side. For small to medium, I feel it is not required but for very large projects I feel this would be a good solution. Again, yes, we will need to add extra code to achive what we need to achive but it would be a good solution. – Burrows

What's the benefit of EF POCO entities over ordinary EF entities for use with RIA? (Please, don't take this as a negative question, I am really interested in this. If POCOs are better, I want to know, so that I can start using it too :-) – Grandmamma

Have a look at this, again I said it before, this is more for enterprise level development msdn.microsoft.com/en-us/magazine/ee335715.aspx – Burrows

I know this article but it does not answer my question - What is the point of using EF POCO with RIA? Self tracking entities and WCF service described in the article is an alternative to RIA, it is not meant to be used with RIA. In the RIA scenario, EF can be used just to connect from your server app to the database (you could use NHibernate, L2S or whatever you want). RIA takes care of the communication between server and client (this is what is described in the article). – Grandmamma

Even with POCO I am still using RIA services to accompolish what I am trying to do. Here is how we are planning to use POCO. We are going to create EF to use entities and use T4 template to create the POCO classes (in seperate dlls based on domain knowledge). In the poco classes we will add our custom domain knowledge class which joins the tables and create RIA services seperately for the domain knowledge. The main idea with this approach is to avoid generating bussiness logic classes at the client side, instead move them to server side where we will have all the tests. – Burrows

If you add files that extend your partial EF classes on the server and call the file with extension .shared.cs, it will be transferred to the client and extend the client classes the same way. Are you already doing it the way you described or is it just your plan? Since I think that it is not possible to make RIA use custom classes as entities on the client (POCOs you generate). So the only way to have domain logic on both sides is to put it into the .shared.cs files. – Grandmamma

Answer 7

I am really disappointed about MS. As it is obvious from the discussion about this topic, I am not the only one who sometimes gets confused by all the "tools" we are provided by MS. The problem is that really miss some managing and coordination from MS.

The result is that there are very similar products with similar functionality where one does one thing better and the other another one. And no one can tell which one is better to use or even which one will be supported in the next version.

I have two examples.

1. Entity Framework vs. Linq to SQL in .net 3.5 These were very similar, both did the same. L2S was meant to be better for smaller projects, EF for enterprise ones. L2S had much better designer and better LINQ implementation. EF was supposed to be able to map more database tables to one entity but this never worked really well. And, by the way, even EF4 does not have a very useful feature of L2S that is AssociateWith<> function. And suddenly, L2S is no longer supported and everyone should use EF. There should be someone who at the very beginning said "Stop, we have two similar technologies. Let get the two teams together and make one product with the best of both.".

2. RIA services vs. WCF Data services Again, the same problem. Two distinct teams working on two similar products. Both with some better features tham the other. But definitely, there could be one product with the features of both.

How should we decide which one to use (besides spending a lot of time to mastering both)? Which one will be deprecated?

...this is probably for a blog post, not answer here. Sorry, I just needed to write it somewhere and since there was a lot of talk about these issues, it seemed as a proper place. I will definitely try to blog about it later.

Grandmamma

I agree Gius. I work for Microsoft, and I was confused myself. The reason why I came to SO, is because I wanted to know a clear opinion from the outside world. I also wanted to see if there are a lot of guys who would be willing to explain if RIA has become bottleneck for their development. Apparently from this discussion, it seems like RIA services will probably not be a show stopper if one decides to go with it. – Suited

On a personal note, I think the problem is now is choice. There are just too many things to catch up with, and it is even more difficult to decide which one is better. – Suited

Answer 8

I have written a post in my Blog about Ria WCF Data Services, and WCF Rest Service using also some of the conclusions reached here it is here.

Exhaustless