I hate MSDN's site for WCF RIA services. It does not say what it is, it only says what it does. It says what it can achieve but does not say why I need it.
For example:
"A common problem when developing an n-tier RIA solution is coordinating application logic between the middle tier and the presentation tier".
Well, it does not mean much to me.
"RIA Services solves this problem by providing framework components, tools, and services that make the application logic on the server available to the RIA client without requiring you to manually duplicate that programming logic. You can create a RIA client that is aware of business rules and know that the client is automatically updated with latest middle tier logic every time that the solution is re-compiled."
So does it download DLLs from server? Is it a metadata describing the rules for the data?
So what is it? Is it just a VS 2010 add-on for RAD? Or is it a technology on top of WCF or underneath it or what? Where does it live? With data, with server, what?
I appreciate if you can summarise this for me please.
Answer
RIA services is a server-side technology that automatically generates client-side (Silverlight) objects that take care of the communication with the server for you and provide client-side validation.
The main object inside a RIA service is a DomainService, usually a LinqToEntitiesDomainService that is connected to a LinqToEntities model.
The key thing to remember in RIA services is that it's mainly a sophisticated build trick. When you create a domain service and compile your solution, a client-side representation of your domain service is generated. This client-side representation has the same interface. Suppose you create a server-side domain service CustomerService with a method IQueryable<Customer> GetCustomersByCountry. When you build your solution, a class is generated inside your Silverlight project called CustomerContext that has a method GetCustomersByCountryQuery. You can now use this method on the client as if you were calling it on the server.
Updates, inserts and deletes follow a different pattern. When you create a domain service, you can indicate whether you want to enable editing. The corresponding methods for update/insert/delete are then generated in the server-side domain service. However, the client-side part doesn't have these methods. What you have on your CustomerContext is a method called SubmitChanges. So how does this work:
- For updates, you simply update properties of existing customers (that you retrieved via
GetCustomersByCountryQuery). - For inserts, you use
CustomerContext.Customers.Add(new Customer(...) {...}). - For deletes, you use
CustomerContext.Customers.Remove(someCustomer).
When you're done editing, you call CustomerContext.SubmitChanges().
As for validation, you can decorate your server-side objects with validation attributes from the System.ComponentModel.DataAnnotations namespace. Again, when you build your project, validation code is now automatically generated for the corresponding client-side objects.
I hope this explanation helps you a little further.