Why use the "RIA Services Link" instead of the OData endpoint?

Question

Before reading, please be aware that I have read all the other messages about the differences between vanilla WCF, WCF data services, and RIA services. My question specifically is why RIA Services is considered as a special type of data source specifically for Silverlight, when it seems that it makes sense to just do it with one task: to serve as a word of business logic behind the REST interface.

It seems that with the release of VS2010, the RIA services have strengthened their position as the level of business logic that lies behind the REST data access service - this, apparently, is confirmed by the new option “Expose OData Endpoint” in the domain service Class Template in Visual Studio, which as far as I can tell, essentially doing for your RIA service exactly what WCFDS does for an arbitrary data source (you can do this earlier, I suppose, but adding this flag makes it clear that the RIA Service can be considered as a layer containing business the logic used to improve the ultimate REST data points and / or limit it to a specified set of queries, and not necessarily the end point itself).

So, if I have an RIA service with business logic that can be opened through OData, I can add a link to the OData service from the WCF client application. On the client, I get a derived DataServiceContext, which allows me to do work with the work style on the client. I can do the same from a Silverlight application and get what seems to be the same thing - a derivative of a DataServiceContext.

If instead I use the "RIA Service Link" link in the Silverlight application to directly bind the application to the RIA service instead of adding the service link, I get the code created by Visual Studio that seems to support almost the same work patterns, but using a different API style.

In this case:

• What are the benefits of a “RIA service link” where a Silverlight application is tied directly to the RIA service, rather than just adding a service link to an OData endpoint that can be used by any client without any close connection? I am told that the magic of RIA is to generate code, so I think I'm trying to understand how the generation of RIA code is generated in the same way as the "add service" code generation.
• If there are benefits, why are these benefits specifically for Silverlight and not for WCF client applications? Selling RIA services solely as a layer behind an OData endpoint looks like this will help standardize and push OData even further in terms of a universal endpoint type for any client - "consume from ASP, consume from Silverlight, consume from WCF ... you get almost the same experience, and it's great. " Instead, we have Silverlight connected directly to the RIA with a special feature set, and all other clients use an open protocol.

Answer 1

RIA services are not intended for the "domain logic behind OData" and vice versa. The intent of RIA services is to disengage from the mechanics of accessing data over the Internet to enable rapid deployment of applications in Silverlight. Think of the RIA WCF Services as VB relate to C ++.

Key benefits of RIA services include:

Access to transparent data - no files with svc files, etc. You create an entity framework model, assure it of a domain service, and you're done. More important changes are distributed automatically. The developer does not update the Service link every time a model or request changes, the gen code does this for you.

Out-of-box authentication framework . This is where you create a business application, this is a template in VS, a way to integrate with an existing ASP.NET authenticator without having to do the hard work.

Data Source Templates and Validation = Probably one of the most overlooked functions, but one of the most important. Did you open the Data Sources window? RIA services create user-customizable DataContexts associated with basic / detailed controls that support server-side validation annotations. A functional data-related application is drag and drop. Think about the value of this for those who are more focused on Design / Blend.

In short, RIA services are designed so that a developer can move from an edmx data model to a secure, functional Silverlight within hours. This is terrific material when used in context.

As a note, I have done quite a bit of research on RIA services and data services, and they fulfill different needs. We use RIA Services for all of our desktop replacement apps, but we use Data Services for SaaS.

I do not think that you are far from the long-term intention of the RIA services. I think we will see that in future versions the oData and RIA services will be much closer.

Answer 2

The OData endpoint provided by WCF RIA Services does not support query operations and returns data as is. This means no benefit from IQueryable, sorting, options, etc. He will simply expose your methods; end of story. Rumor has it that this will change in the next release. However, what RIA Services provides in terms of IQueryable on service calls, the automatic distribution of middle-level business rules to the user interface and INotifyDataErrorInfo for ongoing validation errors for the Silverlight client is outstanding if you decide to use them.