FrankMonroe wrote:
Thank you.
1) So: I understand "No ODATA for LLBLGen .NET Core, whatever the version of ODATA"; am I right?
In our case, that's right.
2) ... or perhaps I can:
If you want OData v4 support, you have to compile the OData support classes library in the runtime sourcecode against the OData v4 library from Microsoft.
Will that ("...compile the OData support classes library in the runtime sourcecode...") work for .NET Core?
The OData support classes built on top of the ORMSupportClasses so converting them to a .netstandard 2.0 project shouldn't be that painful, but you then indeed also need to make sure it works with the MS library for OData for .net core, which as they say, will contain breaking changes as well. The heart of the code though should be the same, i.e. the discovery of what elements to expose.
3) Not _directly _related to LLBLGen but: I get the feeling from your reply that ODATA is on its way out (ie is 'old technology'), (I understand though it's still used by Netflix, SAP, ...). Do you (or anyone who can help) have a suggested newer/better replacement technology?
So many "standards", so little time
OData has always been a bit of an outcast. Its team is still alive it seems, but it's been a niche technique. It's easy to expose a datamodel without doing a lot of work, but in the end, what exactly do you want to provide? Most people I talked to who used it went back to using a normal WebAPI with a REST client, as they're more in control of what's exposed and in what way, i.e. they can control how the model is used, by providing a specific API for that.
Thanks.
PS I understand Facebook is developing GraphQL https://github.com/graphql-dotnet/graphql-dotnet - is this the future?
Be careful with graphql, it contains patented code and FB hasn't released it under a patent-free license. I.o.w.: FB holds your code hostage with their patent clauses.
In the end, you can't avoid doing work, that's the key takeaway: you either have to formulate the queries in the client which then targets the OData API, or you have to formulate the queries in the service and expose the queries as methods in the webapi.
I'd pick the latter, even if it's only for security. Derived models in the designer help a great deal with that too: you can model the shape of what you want to expose with these without external exposure of your entity model.