How is RIA services for relational data efficiency?

Question

I have been researching RIA services with silverlight 4 and considering using it. Switching to silverlight from ASP gives me some concerns about the maturity of silverlight for data driven apps.

I was looking at relational data queries. Lets say I have a 'person' table and a 'cars' table. Multiple cars can be associated with a person. Now if I do queries with relational data I have to specify to include the additional tables to be returned to the client from the server. Shown here:

http://timheuer.com/blog/archive/2010/01/05/master-details-with-ria-services-and-includedresults.aspx

I am a little concerned with efficiency. If I do something like this, it appears I am potentially sending multiple rows from the car table for each person row (since its one to many). However, I may only want the name of the car and not other columns. A more complex example with a bunch of relational joins to other tables could get ugly. Is there any way to address this? I don't see much info on custom/complex types or how ria services handles database views.

Another thought of mine is if I have relational data that loops back on itself will that lock up a query. For example if person links to a car and car links to some other table and that table links back to person. It could seemingly loop forever?

Answer 1

The amount of data transferred (or not) with RIA services is totally up to you. You are not required to include all child table data. Yes, it is possible to write really inefficient data requests, but it is also possible to make them optimal.

Endless loops don't generally occur in ER models. It is no different to running a join on the tables in SQL.

If you are really concerned with maximum efficiency (unlikely at first) you will probably use SQL store procs anyway on the server side and hit those procs with specific parameters to do the grunt work.

I have build several large systems with Silverlight 3 and now working with 4 and personally I will have a hard time going back to ASP.Net now. It is easier to develop in (once you get to know it's quirks) and is actually a lot of fun :)

Hope this helps.