DevForce is more productive than RIA because of its architecture and features.
Most RIA and DevForce applications turn to the Entity Framework (EF) for Entity Data Modeling and data access. DevForce adds a Visual Studio extension that enables customization of EF entity class generation right in the designer itself.
DevForce does not generate (nor require) a server-side DomainService with its hundreds of CRUD operations. DevForce knows what it means to query, insert, update, and delete. If you need to customize those operations, you can; if you don’t have to, you shouldn’t have to.
In RIA you ask a wizard to generate the first version of the DomainService with four CRUD operation methods for each entity type. Then you customize. If your database changes, you can’t simply regenerate because you’ll lose your changes. This leads to a difficult application evolution cycle involving delicate cut-and-paste operations. It’s tedious and error prone.
You can compose almost any query on the client. In the face of an urgent, unexpected application requirement, you can update your client application without touching the server. This save you time and reduce the risks of re-testing and redeploying to the server farm.
These scenarios are easier to address thanks to the DevForce client-side query-able cache. The same LINQ expression can simultaneously query the database and the local cache. Flip a switch and DevForce acts as if it were querying an in-memory database. You can save the cache to local storage and restore it hours later with just two lines of code.
A DevForce entity model class generator replaces the Entity Framework code generator. The DevForce generator emits EF-ready classes that can be serialized over the internet. Those classes afford full support for .NET client data binding and plenty of hooks to inject custom business logic. You can customize the DevForce T4 template to alter or enhance the generated code.
DevForce uses the same entity class model on both server and client. There is only one code base to maintain. Change the source, compile, and you are done.
RIA emulates a single model approach but, in fact, it requires two separate class models that are (a) subtly, often confusingly, different and (b) difficult to keep in sync. The developer relies upon a RIA tool to detect every little Server model change and regenerate the companion Silverlight classes every time … assuming it can find the client project to update.
Developers know that tested code leads to cleaner designs, easier maintenance, and quicker enhancements. You can add features faster when you are confident that you’re not breaking existing code.
DevForce application code is easy to test. When the EntityManager is offline, asynchronous queries that would have gone to the database return immediately with cached data. You can write most of your small integration tests as synchronous tests without the async gymnastics that discourage the Silverlight tester. With the DevForce FakeBackingStore, you can run integration tests that go almost to the database … but don’t actually touch a database. No need for fancy database rollback logic.
RIA emulates a single model approach but, in fact, it requires two separate class models that are (a) subtly, often confusingly, different and (b) difficult to keep in sync. The developer relies upon a RIA tool to detect every little Server model change and regenerate the companion Silverlight classes every time … assuming it can find the client project to update. Compare with the challenging RIA testing story.
Sometimes you need to expose some of your business data to client applications that you didn’t write and you don’t control. They could be non.NET clients. You can grant controlled access to a carefully selected subset of your model using OData.
DevForce offers a complete OData implementation, save as well as query. And DevForce can handle any legitimate OData query. RIA only offers a token OData implementation. A RIA client can’t save and client queries can’t be filtered or paged; a RIA OData query for orders would return every order in the database. In practice, developers have abandoned RIA OData in favor of raw SOAP and WCF Services, a much more difficult, less open route that is especially difficult for non-.NET clients.