Share via

March 2011 CTP of WCF Data Services for OData v3 is Live

  • Article

There is a new CTP out for WCF Data Services (v3), which features the long awaited support for properties on derived types (yay!)
You can get it from here.

The following proposed OData version 3.0 functionality is also supported by WCF Data Services in this release:

  • Multi-Valued Data Types
    OData now enables you to define multi-valued types in the data model of your data service. These multi-valued types contain unordered collections of primitive or complex types.
  • Named Resource Streams
    OData now enables you to define named resource streams for a given entity. This gives you the ability to have more than one binary data stream associated with a given entity. The .NET Framework client library now enables you to access named resource streams.
  • PATCH Requests
    A new PATCH method has been added to the HTTP standard. OData now supports this new HTTP method. WCF Data Services handles PATCH requests in the same way that it handles MERGE requests. The .NET Framework client library now enables you to request that updates be sent to the data service by using a PATCH request.
  • Prefer Header Support
    OData now supports the ability for clients to request whether or not a payload is returned in response to a POST, PUT, MERGE, or PATCH request. This client preference is indicated in the request by the value of the Prefer header. When using the .NET Framework client, this preference is managed by the DataServiceContext.

The following additional functionality is also provided by WCF Data Services in this release:

  • Properties on Derived Types
    You can now explicitly create relationships between derived types. Previously, you could only do this on the base type.
  • Expanded Support for Feed Customization
    Feed customization now supports mapping to the atom:link and atom:category elements and mapping multi-valued properties. You can now also define conditional criteria when mapping to the attributes of specific elements in the returned feed.
  • Support for Entity Sets with Different Base URIs
    The OData protocol allows for a data service to expose entity sets as collections that have different base URIs. Previously, the .NET Framework client assumed that all entity sets shared the same base URI defined in the DataServiceContext. Now, you can define a delegate that is used by the context to resolve URIs for entity sets that do not share a base URI.
  • Including Relationship Links in the Response
    The OData protocol defines a method for addressing relationships between entities by using the $links operator in a URI. WCF Data Services now enables you to request that the data service include these links in entry elements in the response. This behavior is controlled by the IncludeRelationshipLinksInResponse configuration property.
  • The .NET Framework client library now uses relationship links when constructing URIs that address related entities, when they are present in the response.

 Glenn Gailey

Comments

  • Anonymous
    October 27, 2011
    Does this version support EF code first's DbContext object? Or is the ObjectContext workaround you've shared still needed? Thanks

  • Anonymous
    November 01, 2011
    I haven't seen any improvements made to make it easer to to use a Code First DbContext with WCF Data Services. You can go here to vote to add this as a new feature: data.uservoice.com/.../2360134-support-dbcontext-as-a-ef-provider-context Also, I created a topic in the TechNet Wiki that describes how to use EF Code First with WCF Data Services: social.technet.microsoft.com/.../5234.aspx Glenn.

  • Anonymous
    November 22, 2011
    There's an extension library on codeplex that provides access to DbContext and the message body. wcfdataservicepost.codeplex.com

  • Anonymous
    December 16, 2011
    That library is interesting, but it is essentially getting the stream (message body) from the OperationContext of a client response (somehow by reflection). It doesn't really have anything to do with Code First DbContext, and doing this doesn't really follow the OData protocol, which doesn't define support for service operation payload for a POST operation (which is why you have to use parameters).