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).
New Feature Raves
Here is the short list of new features and functionality that I have been looking forward to…
Navigation Properties on Derived Types
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).
Any and All
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)) select e;
My Other Votes
Here are some of my other votes that made into this release:
- Support DbContext as a EF provider context
- Auto generate methods on the client to call service operations (this is provided by the new OData T4 C# template)
For a list of all the new features and behaviors in WCF Data Services 5.0, see What’s New in WCF Data Services.
Still Missing and Not Quite There
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.
JSON Support in the Client
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.
Collection Support for the Entity Framework Provider
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).
Property-Level Change Tracking on the Client
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.
Updates to the Async Clients
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.