I'd be interested to know if there is a plan to port the OData client to work with .NET Standard - this would be far more useful that hard-coding API URLs in the Blazor code. It would mean a developer writing a Blazor app would not need to change any code to work on both Blazor WASM and Blazor Server-Side
Thanks, Hassan! Your OData content has been super useful for my team recently. The only issue we are still having is that is seems AspNetCore.OData doesn't support the $search query parameter. I understand that using filter could solve this, but the front-end framework that we are using wants to send the $search parameter. Is there any chance that this will be changed soon, or that I am just missing something?
Hey Hassan Love your work! :o) I hope you can help with my current issue… I'm trying to stitch Odata into my Blazor app… but I'm having some issues with enums. Before adding Odata I could happily serialize a model at my API/backend then deserialize it back into the same model at the Blazor end. But after adding Odata any enum fields in my model come through as their enum item's name instead of the integer value. This doesn’t deserialize. I understand that by default Odata will return the Enum item's name instead of it's value. That makes sense for an external API but when using Odata as the conduit between my app's front end & back it screws up simple deserialization of objects. Am I missing something? Is there some magic odata serializer setting I can tweak to change this? Alternatively, I understand there has been a .net 'Odata Client' package or 2 out there to wrap all this stuff up. Do any of them currently work with Blazor? Any guidance appreciated… thx
I still see one problem. The actual API that uses EF, is fetching ALL the data from DB, stores it in server's memory and then OData kicks in to filter and massage the Student collection and create a NEW OData collection to send to client. The DB and Web API server is still getting hit with a large collection. How about letting OData engine to talk to DB to ONLY get the data it needs than using EF to fetch ALL data? Does it make scenes?
Returning System.Linq.IQueryable or ActionResult enables OData to translate queries to SQL queries using ef core capabilities. Returning other types such as IEnumerable causes OData to perform queries in the app.
@@kallaskaspar Respectfully I believe you are incorrect. OData filters the results from your controller. So unless you use the odata parameters to modify your query, the server will pull ALL the data (as Ben stated). And at that point, oData would no longer be doing anything aside from providing a standardized syntax. (to be clear, the controller will return filtered results to the client, but the controller itself still still get ALL the results before passing it off to Odata. IQueryable would only benefit you if you were to include the odata commands into the LINQ query to the database).
In VS you can grab the EF sql, it's straight sql without any filters. odata appears to be wrapping the response with API filters in middleware AFTER the data request has been invoked in the initial request. Additionally, if I need a schema, most solid developers create an api documentation endpoint, or use tool like swagger for the data consumers. I'm not a fan of odata and do not see it as a valuable tool for enterprise, long lived apps.
I have a more comprehensive example of just how powerful OData + Blazor is here: blog.jeremylikness.com/blog/build-data-driven-apps-blazing-fast-with-blazor-and-odata/
Awesome, just awesome...
I'd be interested to know if there is a plan to port the OData client to work with .NET Standard - this would be far more useful that hard-coding API URLs in the Blazor code. It would mean a developer writing a Blazor app would not need to change any code to work on both Blazor WASM and Blazor Server-Side
That's actually a great idea Howard, I bring this up in my meetings with the team - thank you for the recommendation.
I have only one thing to say: Sweet! :)
Thanks, Hassan! Your OData content has been super useful for my team recently. The only issue we are still having is that is seems AspNetCore.OData doesn't support the $search query parameter. I understand that using filter could solve this, but the front-end framework that we are using wants to send the $search parameter. Is there any chance that this will be changed soon, or that I am just missing something?
This is just awesome. Just do some advertising OData, many people are not aware of it.
Jeremy is a smart dude.
Core 3 OData release anytime soon?
Hi Tory, It should be out on the 2nd Quarter
@@HassanHabib 2nd quarter of 2020?
@@Mercutio1984 Unfortunately yes.
You can run it today on .NET Core 3.1 devblogs.microsoft.com/odata/experimenting-with-odata-in-asp-net-core-3-1/
@@Mercutio1984 This is a video of how you can use it with .NET Core 3.1 - it's production-ready now: ua-cam.com/video/VGnLZ6Fxnx8/v-deo.html
Amazing
Hey Hassan
Love your work! :o)
I hope you can help with my current issue…
I'm trying to stitch Odata into my Blazor app… but I'm having some issues with enums.
Before adding Odata I could happily serialize a model at my API/backend then deserialize it back into the same model at the Blazor end.
But after adding Odata any enum fields in my model come through as their enum item's name instead of the integer value. This doesn’t deserialize.
I understand that by default Odata will return the Enum item's name instead of it's value. That makes sense for an external API but when using Odata as the conduit between my app's front end & back it screws up simple deserialization of objects.
Am I missing something? Is there some magic odata serializer setting I can tweak to change this?
Alternatively, I understand there has been a .net 'Odata Client' package or 2 out there to wrap all this stuff up. Do any of them currently work with Blazor?
Any guidance appreciated… thx
what chrome plugin do you use for showing json data like that?
Hi Nick, it's called JsonFormatter - here's the link: github.com/callumlocke/json-formatter
I still see one problem. The actual API that uses EF, is fetching ALL the data from DB, stores it in server's memory and then OData kicks in to filter and massage the Student collection and create a NEW OData collection to send to client.
The DB and Web API server is still getting hit with a large collection.
How about letting OData engine to talk to DB to ONLY get the data it needs than using EF to fetch ALL data? Does it make scenes?
Returning System.Linq.IQueryable or ActionResult enables OData to translate queries to SQL queries using ef core capabilities. Returning other types such as IEnumerable causes OData to perform queries in the app.
@@kallaskaspar Respectfully I believe you are incorrect. OData filters the results from your controller. So unless you use the odata parameters to modify your query, the server will pull ALL the data (as Ben stated). And at that point, oData would no longer be doing anything aside from providing a standardized syntax. (to be clear, the controller will return filtered results to the client, but the controller itself still still get ALL the results before passing it off to Odata. IQueryable would only benefit you if you were to include the odata commands into the LINQ query to the database).
In VS you can grab the EF sql, it's straight sql without any filters. odata appears to be wrapping the response with API filters in middleware AFTER the data request has been invoked in the initial request. Additionally, if I need a schema, most solid developers create an api documentation endpoint, or use tool like swagger for the data consumers. I'm not a fan of odata and do not see it as a valuable tool for enterprise, long lived apps.
I have a more comprehensive example of just how powerful OData + Blazor is here: blog.jeremylikness.com/blog/build-data-driven-apps-blazing-fast-with-blazor-and-odata/