I've read a lot about OData with EF Core / ASP.NET Core.
It seems to me that everybody has an opinion on this and It's gotten a bit confusing, so at the risk of sounding dumb, I have a few questions:
Please note:
! I'm NOT talking about the classic ASP.NET 4.6 or 4.7 with EF6 !
! I'm talking about ASP.NET Core with EF Core !
Considering building API - Is there stuff that EF Core alone couldn't handle as well as EF Core with OData?
Considering building API - Is it not better to build clean RESTful APIs instead of OData style APIs?
Isn't implementing OData stuff sacrificing best practices for convenience?
What about long term? Aren't ASP.NET Core + EF Core being built with speed and efficiency in mind and thus won't they be faster and more efficient on their own?
I will go with Shawn Wildermuth's advice that I found on Pluralsight:
OData means that queries are on the client so that versioning OData
services becomes risky and it feels like MS is moving away from it so
I don't have confidence in the long-term viability of it either.
OData on ASP.NET Core/EF Core works very well. Versioning can be accomplished with microsofts versioning api.
I don't necessarily see MS abandoning this technology. There main api (ms graph) is odata 4 compatible.
Using Odata on top of EF Core is really enjoyable for many use cases. Especially the querying part I like a lot.
For implementing writes/commands I usually fall back to webapi/Mediatr.
Here https://www.jannikbuschke.de/blog/cqrs-with-mediatr-and-odata/ and here https://www.jannikbuschke.de/blog/odata-getting-started/ I wrote some thoughts/guides on this topic.
One downside is tooling and community. There is not a whole lot out there.
Related
I know EF Core is a complete rewrite from ground up. Wanted to know about the performance/memory footprint improvements made in EF Core compared to EF.
Am having a .net core 3.1 web-api, I will have to use Postgresql. Wanted to know whether using an ORM(like EF Core) is a good solution?
Or is there any other better data access technology(no ORM or dapper) which can be highly performant to access Postgresql in .net core 3.1 application?
I do not know if this is a valid answer as I am the author of this, but it is something that you may looking. Please have a look at RepoDB.
I heard that companies that use Java technologies, they used to build their own custom Framework that wraps Hibernate. However, is it really feasible for their .Net peers to do the same thing with NHibernate or Entity Framework?
This is almost always a horrible idea - I think Ayende sums it up best in this article. In general, you should consider NHibernate itself to be the "wrapper" around your data access - attempting to build an abstraction layer on top of it is probably going to be a losing proposition.
Actually, you should check out some of the articles on .NET Junkie's weblog. He wrote several great posts on how to deal with repositories, queries, commands and so on. We've been using these in a very large enterprise system where we switch between an in-memory dictionary, an in-memory SQLite database and a production environment using SQL Server or Oracle. Obviously, we use NHibernate for this.
I use the repository pattern and a separate project/dll to abstract away the data framework nhibernate / entity framework. this is a good starting point http://codebetter.com/petervanooijen/2008/04/04/wrapping-up-nhibernate-in-repositories/
I couldn't found a clear answer on that:
Is the ADO.NET Entity Framework a full featured persistence framework like Hibernate for Java?
Is there a any (other) persistence framework in .net? I only found open source frameworks like nHibernate but no clear answer if there is something build-in in .net. What's the best practice to get persistence in .net?
when you talk about persistence layer, usually that is databases or file systems, when you talk about Entity Framework it is called ORMs, and yes, I think in the .Net environment NHibernate and Entity Framework should be two of the most popular ORMs.
ORMs help you to think about your data as objects in your domain, instead of thinking about tables and fields and rows, so it abstracts the technical aspect of persistence and gives you a more model-driven approach while you are writting software.
I use to read a lot about domain-driven design as an architectural guide, but now here in stack overflow I've received many suggestions on using hexagonal architecture, all these patterns and practices help you to buidl better software, and I guess we will never stop learning. So yep, think about ORMs like artifacts to help you focus on more important aspects of your code rather than just making tables and querys. Hope it helps,
I have been using ADO.net since 2002/2003 and most of the application I have developed so far use ADO.net (I do use business objects in my application but underlying data access is through ADO.net)
Question: What is/will be next paradigm of data access technology assuming you are using .net framework and SQL Server?
I am hearing LINQ and Entity Framework but not sure about LINQ or at least its future?
Any advice along with a recommended book will be greatly appreciated.
Object relational mapping is perhaps the next paradigm for data access technology after ADO.NET, although you could say that its already pretty well established. Although Entity Framework is still fairly new NHibernate has been around for several years, and its Java predecessor since 2001.
If you are looking for a good book about NHibernate and object relational mapping in general then NHibernate in Action is good. Its very readable and the first chapter, which is available as a free sample, covers the rationale behind ORM as well as comparisons between NHibernate and other technologies like LINQ.
LINQ is here to stay, what I think you are referring to is LINQ to SQL which while not being very actively developed by Microsoft, is still alive however Microsoft are making it fairly clear that EF is the future.
I am having a bit of a free time and i am planning to catch up on some new technology. I started of my .NET development career as a ASP.NET developer. Presently I am done with ASP.NET development,for that matter i am done with any front end development. These days i am into Business layer and DAL development with the primary focus on WCF service development and I am going to continue doing so. Given the situation which one would be helpful for me in moving forward? ADO.NET data services or Entity Framework?
Those are two totally separate items:
ADO.NET Entity Framework is a data-access and data-modelling technology to handle database storage, modelling objects etc. on top of that
ADO.NET Data Services is a REST-ful way of exposing such data models to a wide audience, by means of browsers and URLs
So basically, first you need to know a bit about Entity Framework, and then you should learn how to make that available to the world at large.
Marc
ADO.NET Entity framework and ADO.NET Data Services are different