Multiple client technologies

DevForce and RIA Services share a common mission: to help you build a richly interactive, data-driven, distributed application end-to-end. "End-to-end" means from the data tier to the client’s screen.

It is a hard problem. The hardest part—and the greatest contribution—is the support for client-side programming. You value DevForce or RIA Services for their transmission and representation of remote data as client-side entity graphs, for client-side validation, for change tracking and for batch saves as transactions. They’re powerful as integrated client + server frameworks. 

Silverlight

DevForce and RIA Services are products with a .NET server side and a Silverlight side. They both provide components that deploy on server and Silverlight client; you write code on server and Silverlight client.

.Net alternatives

Only DevForce also supports alternative .NET clients such as ASP (web and MVC), Windows Forms, and WPF with the same components and capabilities as its Silverlight client.

RIA Services does not. RIA Services is a Silverlight-only story.

True, non-Silverlight clients can consume RIA Domain Services; see Brian Noyes’ excellent post explaining how to do that. That’s not using RIA Services. That’s a workaround, a back-door to recovering a fraction of your investment in an existing RIA Services application—the portion of your investment on the server. Everything RIA Services does for you on the client and everything that you have written for the Silverlight client is off limits. Validation, change tracking, caching, saving, navigation … they are all gone. To non-Silverlight clients, RIA Domain Services is just a collection of SOAP services. 

You would never set out to write RIA Domain Services if you intended to build a "headless", client agnostic service or a Windows Phone application or an application targeting non-clients. You’d more quickly deliver a better, more maintainable result with raw WCF Services or WCF Data Services (OData).

DevForce, by contrast, excels in distributed applications for most .NET clients. You can program for Web Forms, ASP MVC, Windows Forms, and WPF in the same way using the same client code as you program for Silverlight.

OData

Windows Phone is different story. Both DevForce and RIA Services must wait for a future version of the WP7 Silverlight platform to provide certain critical missing features. Until then, phone application developers must access data of an existing DevForce application through the server and live without the rich, DevForce client programming model. This misfortune is ameliorated significantly by DevForce support for OData.

RIA Services advertises a minimal OData option whose limitations Brian Noyes summarizes as follows: (emphasis ours)

RIA Services allows you to expose a query-only OData endpoint (no updates) from your domain services. The exposed feed only allows you to retrieve the entire collection exposed by a query method. You cannot pass query filters or paging operations.

Imagine always having to retrieve every order in the database, being unable to INCLUDE related entities, or save changes. RIA Services OData is unusable in any realistic scenario.  In practice, RIA Services developers must resort to the kind of WCF SOAP services programming that RIA Services promised to replace.

RIA Services intends to provide a more complete OData implementation but has not released that version as of this writing.

DevForce OData is a full, read/write OData implementation supporting filtering, ordering, paging (top and skip), expand (INCLUDE), and service operations. Non-.NET clients such as Excel, SharePoint, iPhone and iPad can access a DevForce application with OData.

DevForce is designed for developers building end-to-end applications targeting Silverlight, WPF, Windows Forms, and ASP clients. DevForce OData helps you extend your reach to other kinds of clients, capitalizing on your DevForce investment, with relative simplicity.