[转]Composite Keys With WebApi OData-白红宇

[转]Composite Keys With WebApi OData

阅读量：5160 次

发布时间：2019-06-13

本文共 4025 字，大约阅读时间需要 13 分钟。

本文转自：

In our basic configuration we told the model builder that our entity has a composite key comprised of an ID and a version:

                       public void MapDataServiceRoutes(HttpConfiguration config) { var builder = new ODataConventionModelBuilder(); var entity = builder.EntitySet
          ("Packages"); entity.EntityType.HasKey(pkg => pkg.Id); entity.EntityType.HasKey(pkg => pkg.Version); // snip }

This is enough for our OData feed to render edit and self links for each individual entity in a form like:

http://localhost/odata/Packages(Id='Sample',Version='1.0.0')

But if we navigate to this URL, instead of getting just this one entity by key, we get back the entire entity set.

To get the correct behavior, first we need an override on our PackagesODataController that gets an individual entity instance by key:

                       public class PackagesODataController : ODataController { public IMirroringPackageRepository Repository { get; set; } public IQueryable
           Get() { return Repository.GetPackages().Select(p => p.ToODataPackage()).AsQueryable(); } public IHttpActionResult Get( [FromODataUri] string id, [FromODataUri] string version) { var package = Repository.FindPackage(id, version); return package == null ? (IHttpActionResult)NotFound() : Ok(package.ToODataPackage()); } }

However, out of the box WebApi OData doesn’t know how to bind composite key parameters to an action such as this, since the key is comprised of multiple values.

We can fix this by creating a new routing convention that binds the stuff inside the parenthesis to our route data map:

                       public class CompositeKeyRoutingConvention : IODataRoutingConvention { private readonly EntityRoutingConvention entityRoutingConvention = new EntityRoutingConvention(); public virtual string SelectController( ODataPath odataPath, HttpRequestMessage request) { return entityRoutingConvention .SelectController(odataPath, request); } public virtual string SelectAction( ODataPath odataPath, HttpControllerContext controllerContext, ILookup
           actionMap) { var action = entityRoutingConvention .SelectAction(odataPath, controllerContext, actionMap); if (action == null) { return null; } var routeValues = controllerContext.RouteData.Values; object value; if (!routeValues.TryGetValue(ODataRouteConstants.Key, out value)) { return action; } var compoundKeyPairs = ((string)value).Split(','); if (!compoundKeyPairs.Any()) { return null; } var keyValues = compoundKeyPairs .Select(kv => kv.Split('=')) .Select(kv => new KeyValuePair
           (kv[0], kv[1])); routeValues.AddRange(keyValues); return action; } }
        
     

This class decorates a standard EntityRoutingConvention and splits the raw key portion of the URI into key/value pairs and adds them all to the routeValues dictionary.

Once this is done the standard action resolution kicks in and finds the correct action overload to invoke.

This routing convention was adapted from the WebApi project.

Here we see another difference between WebApi OData and WCF Data Services. In WCF Data Services, the framework handles generating a query that selects a single instance from an IQueryable. This limits our ability to customize how finding an instance by key is done. In WebApi OData, we have to explicitly define an overload that gets an entity instance by key, giving us more control over how the query is executed.

This distinction might not matter for most projects, but in the case of , it enables a mirror-on-demand capability where a local feed can fetch a package from another server on the fly, add it to the local repository, then send it back to the client as if it was always there in the first place.

To customize this in WCF Data Services required significant .

Series Index

转载于:https://www.cnblogs.com/freeliver54/p/6934298.html

你可能感兴趣的文章