Great news…WCF Data Services 5.0 was released today!
This new product release provides client and server support for OData v3 for the .NET Framework and Silverlight. Previous versions of WCF Data Services were actually part of the .NET Framework and Silverlight, but this out-of-band version is actually it’s own product—designed specifically to support OData v3. As such, I wanted to specifically call out my favorite new features supported in this release (and of course in OData v3).
Here is the short list of new features and functionality that I have been looking forward to…
This might be the single most asked for feature in this release. At least, it was number one on the wish list, with 495 votes. While I’ve only had to work around this limitation once so far, I’m glad to see it’s finally here!
It used to be that you could only have one resource stream per entity type. Now with named streams, you can have as many properties of Stream type defined on the entity as you need. This is great if you need to support, say, multiple image resolutions on the same entity or an image and other kinds of blobs. For more information, see Streaming Provider (WCF Data Services).
I’ve created dozens of service operations to enable my OData client apps to traverse many-to-many (*:*) associations. I sure am glad to now be able to write queries like this:
var filteredEmployees = from e in context.Employees
where e.Territories .Any(t => t.TerritoryDescription .Contains(territory))
This was number three on the wish list. For more information, see LINQ Considerations (WCF Data Services).
Here are some of my other votes that made into this release:
For a list of all the new features and behaviors in WCF Data Services 5.0, see What's New in WCF Data Services.
And, in the interest of fairness, here are the things that I still wish were in WCF Data Services and maybe also the OData protocol. Some of these are still on the wish list.
It wasn’t until I got into mobile device development that I really saw the value of JSON versus Atom in reducing bandwidth, and the OData protocol supports both. While WCF Data Services has always supported JSON in the data service (with this caveat), the client has only ever supported Atom. (As you can see in Pablo’s post, Atom is hugely more verbose than any JSON.) Interestingly, in this release the client has been revised to leverage the OData Library for serialization, as does the server, and ODataLib supports JSON. This means that the client should also also have the ability to “speak” JSON—so please OData folks, turn it on!
It looks like the Entity Framework team has already added enum type support to the forthcoming EF version 5. As such, I would have loved to see this support added to OData as well. Plus, I hate to mention it, but Support Enums as Property Types on Entities is a close second in votes with 491.
Support for collection properties has been added to both the OData protocol and is available when using custom data service providers. However, there is no way to make this work with Entity Framework. I understand the difficulty with mapping an unordered collection of types into a relational database, but it still makes me sad. I am not going to implement a custom provider just to use collections (plus I want enums more).
This is not such a problem, but it’s just a little irritating that while OData supports property-level updates with a MERGE request, the client has never supported this. It would be a good way to reduce some network bandwidth. A workaround for this does exist, but as I mention in this post, you must essentially write a wrapper for DataServiceContext that does property-level tracking and rewrite outgoing MERGE requests.
Well, in this release we now have service actions, although I still find them very hard to both conceptualize and implement for an EF provider—akin to custom data service providers. What I really want is service functions, which is in OData v3, but has yet to be implemented by the WCF Data Services product. Hopefully, when we get functions they will be a bit easier to implement than actions for then Entity Framework provider.
This release also includes an updated client for Silverlight that supports OData v3. Now we just need an updated OData v3 client for Windows Phone 7.5, which is not included in this release. Also, and perhaps more importantly, there is as of yet no publicly available client for Windows 8 Metro apps. We really need this Metro client support in Visual Studio 11, so let’s all hope it makes it in there by RTM.
Oh, and did I mention that all the clients needs to support JSON, especially the Windows Phone client? Although, this new discussion about a lighter JSON format for OData gives me hope for more JSON-centric clients in the future.
Anyway…be sure to try out OData v3 and WCF Data Services 5.0.
Excellent review! I've just upgraded now from october CTP and suddenly all the JSON support is gone!??!
How can I turn it back on?
I was not aware of any change in the JSON behavior between the previous CTP and this final WCF Data Services 5.0 release. How were you using the JSON support before?
Ha! They have added a weird thing: a new mime type: application/json;odata=verbose
Here is the detalied error message:
A supported MIME type could not be found that matches the acceptable MIME types for the request. The supported type(s) 'application/atom+xml;type=feed, application/atom+xml, application/json;odata=verbose' do not match any of the acceptable MIME types 'application/json'
Wtf? How are browsers supposed to send that odata=verbose uglyness?
I guess I'll hack the WCF Data Toolkit and change client's "Accept" header from "application/json" to "application/json;odata=verbose" so that it will work seamlessly as before!
Hi Glenn, how can we query using the url for Any/all for multivalue properties??
.it seems it doesn't understand any(....
Sorry, my Any() code example got chopped-off...
I don't currently have a MultiValue property (which is now called "Collection", by the way) in any of my OData v3 models, but it should work the same as a navigation property. This means that my above LINQ code gets translated to the following URI:
Note that "t" is the alias for Territories in the expression.
For more info, see the OData.org post: www.odata.org/.../even-more-any-and-all
Regarding the change to 'application/json':
Included in V3 of the OData protocol is a new more efficient JSON format which will be the primary JSON format going forward (the format itself has been described in part on OData.org and on the mailing list). In order to support this, V3 requests for 'application/json' will result in a 415 status code on the 5.0 RTM release. You can work around this by either specifying 'application/json;odata=verbose' as mentioned above, or by including a 'MaxDataServiceVersion' header value less than 3 (its generally a good practice to include this header whenever possible). The team is currently working on implementing the new format and will provide an updated version of WCF Data Services and the standalone OData library when it is complete.
Some relevant links:
Is there any chance we'll see an updated T4 template for Service Operations now that 5.0 has been released? We'd love to upgrade to the latest, but our clients need to have client stubs generated and the existing one fails.
Did you hear any news on supporting JSON in the OData client for Mango?
Good info. Started using it.