How do I choose between WCF, REST, POX and RIA services for a new Silverlight application

Question

There a lot of different ways a Silverlight application can connect back to it’ server. Including

• WCF - Windows Communication Foundation
• REST (see also)
• ADO.NET Data Services (or is this just REST?)
• POX - Plain Old XML (E.g basic xml)
• RIA services

For each of these please say what it’s for and when you would or wouldn’t use it. I am not looking for a great level of details just a set of “rules of thumb” for choosing between them.

(The problem is when designing your first Silverlight application knowing what to use when you don’t have time to learn all of them.)

If I was to replace Silverlight with WPF in this question what effect would it have on your answers? (I am assuming with WPF that due to firewalls and admin policies a direct connect to the database is not an option.)

Answer 1

My two (euro) cents:

WCF seems best suited when the service can be viewed as the business layer of the application, that is, when your service has "intelligent" operations like "CalculateDiscountForClient".

ADO.NET Data Services (indeed, just a REST implementation) seems appropriate when your application is basically data-centric and the service is simply a front-end for the database. That is, all your service methods are of type GetCustomers, CreateInvoice, etc.

RIA services is a very new technology that I haven't experimented with yet, but it seems to be useful to create applications in which the Silverlight part and the service are very tightly coupled: you define your service classes and methods in the service project, and they are automatically replicated to the Silverlight project in design time. Also, you can define both WCF-style "action" methods and ADO.NET Data Services-style "data" methods. Looks promising.

Use POX if there is a chance that you change the client part from Silverlight to any other technology (for example HTML+AJAX) in the future, since it is the most interoperable option.

About differences for WPF, the only I can think of, is that for data access, whenever possible I would use direct ADO.NET data connections (properly embedded in a data access layer, LINQ to SQL or the like) instead of ADO.NET Data Services, since it is way more flexible. I must say anyway that I have never developed anything in WPF.

Answer 2

We use RIA, and that's the only one of the options that I know, but I do know it, so here's some of my thoughts.

RIA isn't finished yet. It is being worked on. If you are planning to be finished soon, and you're worried about having to support something that has a potential to change quite a bit, then you might want to consider other options. If this is a new project, and you're going to be supporting it for a long time, RIA will probably get easier to use.

Having said that, I kind of think that there won't be many changes in the way the July Preview of RIA works and the way that a finished version will work. Also the level of support seems to suggest that this will become "The Way" to talk to a server in Silverlight.

Just cause it's worth mentioning, have some links:

http://blogs.msdn.com/brada/ Brad Abrams has an example that he is continually updating.

http://forums.silverlight.net/forums/53.aspx this is where you go to ask questions.

http://www.riaservicesblog.com/Blog/ Colin Blair knows his stuff, and he is very helpful.

Answer 3

I think I would not go POX ever again. If you write WCF so that the service itself is independent of the binding and binding is done in configuration files, then WCF is pretty much agnostic about transport and protocol. It can do SOAP, JSON, REST, or its own form of binary serialization. All of this is in the binding. Internally, WCF only specifies what gets exposed in terms of operation and data contracts (all defined by class, method, and property attributes). WCF gives you tremendous flexibility in this regard, with more to come in 2010.

From the Silverlight side, WCF requires that you write some plumbing code. The .NET frameowrk has the tools to build the proxy in your Silverlight project, but you must be prepared to handle all WCF responses asynchronously, and the proxy cannot catch exceptions thrown by the service.

.NET RIA Services hides all this. It uses WCF under the covers, but that is completely hidden. You don't have to write asynchronous code. You define validation once, mostly declaratively, and it works both server-side and client-side. Release 1 will be targeted for Silverlight, so you don't get the versatility to use the service elsewhere. That scope is supposed to be broadened in later releases.

I don't know enough about ADO.NET Data Services to compare. I suspect the answer would depend on whether you want to expose your data to more than just Silverlight usage.

.NET RIA Services looks like the direction I'd want to go (looking at these issues myself, with a large application in mind). The big issues for me will be implementing a very large collection of functionality in the service layer, and not being able to code directly to the data access layer (we have to be able to run on either SQL Server or Oracle).

Using WPF instead of Silverlight changes everything, depending on where your data resides. It's like the old question of Winforms vs. ASP.NET. With WPF, you're building a Windows client app, and you don't need to use any form of service-based data interface at all, unless your data access forces you into it. You'll still want to separate data and business from presentation code, using MVVM, MVC, or MVP. Other than that, you have the option to treat data access as a layer, rather than a wholy independent tier.

Answer 4

WCF is Microsoft's standard for service communication. I would strongly advise anyone to create a service layer using WCF Web APIs (uses WCF, but tailored specifically for REST), which is coming out this April 2012. WCF Web APIs is currently in preview mode.

Remember these rules of thumb: - your UI will change faster than your service layer. RESTful services will be around in several years, Silverlight probably won't - will your services ever be APIs? Well...WCF REST is the way to go - will you mix JavaScript and Silverlight code? WCF REST will make your life easier - will you have a mobile component (since Silverlight won't run on iOS or android)...REST is preferred.

Don't tailor to the technology, but the app as a whole.

Answer 5

If you want to create a Silverlight Application and you do not care about other clients, then I would choose RIA Services. It is quite painless to use and you do not need to worry how the connection from the client is made (i.e. no client side configuration necessary). RIA also generates classes for all your entities on the client and you can even share your own "server" code with the client if required (useful for enumerations or extension methods).

Remarks:

• I never tried this, but if you really need you can access the RIA Service also with other clients, after all RIA Services are built on top of WCF services.
• I do not quite understand Akash Kava's security concerns. You can (and have to) control security on the server-side as you would do with any other service.