Brief:

 

It's on our roadmap for this year; until then, use the Data Services facade for Entity Framework

 

Discussion:

 

Would you please explain what you are trying to do?

 

DevForce and RIA Services are really about providing and end-to-end programming experience with rich objects on the client ... where you are responsible for building the client application.

 

Data Services (OData) is about serving up data (not business objects) to anyone willing (and authorized) to receive them.

As a recipient of OData there is nothing on the client to program against. It's just ... data ... whether delivered as JSON, ATOM or POX. And don't be mislead by the lame client proxy code generation. That's little more than a CLR representation of the data.

 

Btw, I'm not knocking OData. I think its great ... for broadcasting your data to unknown client applications. If I'm NetFlix and want the world to query my catalog ... which costs me nothing and makes it easier for anyone to learn what films to rent from me ... this is way cool.

 

It's another story altogether if you're building a Forms-over-data business application for known categories of users. If the application takes user input and must reason about it. If YOU want to shape the interaction. If YOU want to validate input, etc.

 

RIA Services has a read-only OData facade for "external clients". Sure you can expose the service results as JSON. Then what? Consumers of this data will not benefit from the RIA Svcs client entities. About all they're getting from the deal is access to the same object shapes as provided by the RIA Svcs service on the web. Frankly, this ain't saying much.

 

If you built your model with EntityFramework (and most folks should) ... either for RIA Services or for DevForce ... then why not hop right to the Data Services option that wraps your EF model? It is unlikely that your RIA Svcs/DevForce entities have a different shape than your EF entities and, since you're chucking out all the business logic anyway (as you must with Data Services) , what have you gained?

 

I'm not sure. I do know that we are getting this question. And we have expect to provide an OData facade over a DevForce model in 3rd or 4th quarter 2010.

 

Action:

 

Meanwhile, I ask people like yourself to take a serious look at your requirements. Serious. Not "what's cool". Not "we'd like to be able to someday". Serious. As in "we've got money, deadlines, careers riding on these outcomes."

 

If you're building a substantive Forms-Over-Data for Silverlight / ASP / WPF customers where client-side execution, responsiveness, richness matters ... then you need DevForce.

 

If you're offering data as a service to "subscribers" on any platform running anything and you're not accepting much data back ... willing to take what you get from them in a rudimentary way ... but the real focus is on broadcast-into-the-ether ... then stay away from RIA Services and DevForce. Go straight to WCF Data Services. The effort (and, with RIA Services it will be a lot of effort) is not worth what you're trying to accomplish ... and can accomplish more easily with Data Services.

 

If you need a blend of both worlds ... we still have something to talk about. I'd say ... go DevForce, use the EF Data Services facade for now, and we'll be ready with our OData facade by the time you have an application worth sharing with the world.

 

p.p.s.: XPO?  Please ... I hope you're kidding. Makes no business sense whatsoever. Unless you don't care about being in business.

 

p.p.p.s: I have a few opinions on this subject :-)

 

 

 

Hello!

 

Domain Services can be configured with JSON endpoint, and Data Services has support for a specific JSON format, too (OData).

 

What's the story on supporting JSON endpoints with DF2010?

 

Would it be feasible to use to support WCF Data Services with a suitable provider implementation for DF2010, along the lines of for example:

 

- ADO.Net Data Services IUpdateable implementation for Linq to Sql

 

 

Any help is appreciated!