We are currently looking at converting from WCF Data Services to WebApi with Odata. Our entity model is defined using an entity framework defined as an edmx. Im struggling to get the edmx working with WebApi OData due to relationships and complex properties.
I'm just wondering whether someone has successfully implemented webAPI with odata on a bigger sized edmx (that has relationships as well)? Any advice would be great.
You may try using RESTier -- a .Net framework built upon Web API OData. There are several things you may need to pay attention:
RESTier has an EF provider which is quite similar with WCF data services. So it should work wiht the edmx model with little tweak.
RESTier is not a "competitor" for Web API OData, it's built upon Web API OData and can fallback to Web API OData.
RESTier currently is a preview version, but it has good support for the common features used of OData service.
If you tried out and find it cannot work, you can create an issues on https://github.com/odata/restier/issues with more detailed information, if you successfully make it work, it will be great you share your experience.
Related
I'm new to .NET Core and Blazor, with mostly WebForms and MVC experience.
All the Blazor documentation and tutorials I've found use a separate API project and access data through HttpClient and Json serialization/deserialization. I see why this would be necessary for client-side Blazor using WebAssembly, but for Server-Side Blazor using SignalR what's the best way to access the database directly from the components' .razor files using an Entity Framework DbContext?
For example, in an MVC controller you can just do something like:
private ApplicationDbContext context = new ApplicationDbContext();
and then query the data by doing something like:
var things = context.Things.Where(t => t.ThingAttributes == something);
Is there an approach that is this clean and efficient when working with components in server-side Blazor?
Sorry for the broad nature of this question, feel free to point me to blogs, docs, or tutorials I should have already read. Thanks!
What you call a controller should be turned into a service class, that retrieves data from the database, and pass it to the calling methods. You should add this service to the DI container in the Startup class. To use this service in your components you should inject it like this:
#inject DataService myDataService
I think that the Blazor templates come with sample how to define such a service and use it in your components.
Here's a link to a sample by the Blazor team how to create a service and how to use it in your components. The service doesn't use Entity Framework, but this is something really minor I'm sure you'll cope with.
after lot of search, do not found any good and concise information which does not use the EF and still implement the OData standard. For example: Create an OData v4 Endpoint Using ASP.NET Web API 2.2
very well described with EF.
Does anyone have good source without using EF. (I was more interested into using the t4 template custom tool, generated dto classes etc.)
my ultimate goal is to use OData api in Power BI OData feed which must have the OData standard and not using EF(Entity Framework)
although it seems that there are couple of duplicate but none of them have enough info.
My application currently accesses SQL Server the "traditional" way - via EntityConnection on top of SqlClient. I would like to add the option of accessing SQL Server via a new OData service. Any ideas on the best way to do this? Is it possible to reuse the existing model-first EntityObject-derived classes? Thanks!
The best way would be to follow this tutorial to create an OData service: http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/create-an-odata-v4-endpoint.
Update adding more details given the comment:
Although the link should be enough for answering the question, I can also elaborate on the end-to-end scenario a little bit.
Now the premium experience of creating an OData V4 service out of an SQL Server DB is to use the ASP.NET Web API 2.2 for OData V4. With the help of the code-first aspect of entity framework you can create an OData V4 service that supports pagination, queries, and CRUD operations in a very reasonable time (about 10 minutes for every table in your database).
As soon as the service is created, various client libraries that supports consuming V4 services can be at your service. The premium experience on the .NET platform is the OData v4 Client Code Generator.
If your consumer is a non-developer, Power Query can help you import the data from the OData service. Their support for V4 services will come early next year according to this, but Excel and Power Pivot already natively support consuming V1-3 services. For creating a V1-3 service, the tutorial next to the one I gave at first would help.
I like all the features that JayData provides. I am wondering for when I occasionally have a non-O-Data restful service if there is a way to manually hookup CRUD ops to my existing jaydata entity definitions so that I can take advantage of all the kendoui/knockout goodness that comes with this.
Is there any example where a jaydata entity definition is manually hooked up to restful service url kind of like the jquery method?
Thanks
Our webapi provider is what your are after. Do not worry about its name, webapi is a microsoft framework for rest apis, hence the name, but it should work with other restful endpoints, php, java, ruby, etc. Of course it is only good for crud, as filtering, paging, ordering and projection is only standardized in odata. Also, for paging length() is needed, so that must be implemented on the server side, too.
Give it a try and tell us about your experience, good or bad, we're to help you.
Or consider using oData, JayData can act as an odata endpoint on the server side, we also have hosted odata service.
In general, are WCF Data Services interoperable or Microsoft specific?
This ADO.NET Blog link shows very nice how EF could be used in WCF Services. But it also shows in that simple example a method with return type: IQueryable<Patient>. Is this breaking the interoperability?
Is there any special treatment regarding these Data Services with EF to be interoperable? Are there tips or things to take care in this matter?
This MSDN overview says WCF Data Services are interoperable. I believe returning IQueryable<> is to support the OData query expressions.
I'd assume you won't have to do anything special (other than maybe exposing the services with WebHttpBinding and WebHttpBehavior).
If you're evaluating technologies you may want to look into ASP.NET MVC4 Web API as an alternative to WCF Data Services. Take a look at this blog and this forum post.