How does an EF6 model and a WebAPI 2.2 + OData 4.0 model, relate?

4
votes

It's been a couple of years since I worked with EF and OData. Back then, OData was on WebAPI was limited to some URL filters, but even that was pulled at the last minute before MVC 4 RTM.

A lot has changed.

Now I have a model-first EF6 project with an EDMX file, since I like to visually plan my model. I am also building an OData service for this app, using WebAPI 2.2 and OData 4.0.

There's a comment on the question below:

"Unfortunately, at this time the EDM model used by EF is different from the EDM model used by Web API OData."

OData exception The complex type 'WebTools.Order' refers to the entity type 'WebTools.Customer' through the property 'Customer'

Which is understandable, the separation is best for public APIs.

However, I'm confused because the quick start tutorials on the web (see below) seem to be using the same EF (code-first) model for both OData and the database.

Does that mean that the models are no longer different, the comment above is old? Or does it mean that I must go code-first if I want to just expose my database model?

And since the tutorials seemingly show exposing a single EF database model, then how does one go about separating and having two models?

I'm having difficulty finding/trusting online resources because these technologies are so fast-moving.

Luke

1
asp.net-mvcentity-frameworkasp.net-web-apiodata
I'm getting the sense that code-first has won. I'm also finding that the idea to disentangle the OData and EF models is impractical because of the IQueryable interface has to run right through the API into the ORM/data layer. This removes much of the benefit of using WebApi for OData, since I can only have one model, so I may as well just use EF model first and let WCF Data Services open it all up to Excel. – Luke Puplett

1 Answers

3
votes

Here's what I've learned so far.

  • OData v4 does not support plugging-in existing model-first EDMX model classes.

  • It does support exposing an 'arbitrary' model built from POCO classes, relationships between entities are not expressed in such strong terms, but the v4 model is more like an object hierarchy and can even have a single root 'node' and all the child items and collections of items can branch off, a graph.

  • This is all done much more losely using just routing rules and some simple conventions for the models and controller action names.

  • It's therefore possible to build an OData service around an in-memory structure, or no-sql or composed of other services.

  • However, when it comes to an SQL source and EF, then the model must be united in order for the IQueryable logic to flow, but also for field-name mapping.

  • Since the OData v4 model builder only supports POCO classes, you must go code-first.

  • OData v4 with EF is thus limited to greenfield projects or those that feel there's enough value-add in v4 to warrant rebuilding code-first.

  • I am researching code-first automatic POCO generation from an existing database. This would allow the EDMX to generate the SQL database and then "roundtrip" it back into code via auto POCO generation from the DB. Having never used code-first, I'm not sure if this is something it can do.

Important As of January 2015, neither Excel or LinqPad support v4. The metadata is different, I think due to the lack of 'formal' relationships. This makes v4 not very appealing at present, especially when WCF Data Services can build a full service from an existing EDMX in a few seconds.

Updates

1/

Code-first from existing:

http://msdn.microsoft.com/en-us/library/jj200620.aspx

2/

You can exclude entities from an EF model, even if they are referenced in other entities, by applying [NotMapped] or modelBuilder.Ignore<InMemClass>(); if using the fluent API.

Luke