It think your largest problem at this point is just sourcing information properly. Admittedly, it's a bit confusing, especially for someone completely new on the scene.
A little background to start: there's ASP.NET, ASP.NET MVC, and ASP.NET Core. ASP.NET is really nothing, although it became short hand for ASP.NET Web Forms, as that was the only thing you had to work with at the time. Then, Microsoft introduced ASP.NET MVC, which took the foundation of ASP.NET and layered on an attempt at a modern web application framework modeled after the MVC (model-view-controller) pattern. It was a vast improvement over Web Forms, but did not fundamentally break away from the older system enough to make it a truly great application development framework. Because of it's reliance on System.Web (a monolithic family of DLLs) and the full .NET Framework, it was slow, hard to deploy and completely incompatible with things like containerization. Enter ASP.NET Core, which was a complete rewrite from the ground up.
ASP.NET MVC had a sister framework in ASP.NET Web Api, and technically you could still employ ASP.NET Web Forms in the same project. In fact, a single project could utilize all three frameworks at once, which is as convoluted as it sounds. ASP.NET Core, at least initially, did away with this confusion by just having a single system for both traditional web applications and APIs. As such, if you're looking for information about Core, it's just "Core". Looking for ASP.NET Core MVC is just going to lead you to outdated information.
That said, frustratingly, Microsoft decided in their infinite wisdom that Web Forms, though reviled by most every developer who had ever used a real web application framework, were actually so awesome that they should be resurrected, at least in spirit. Thus was born Razor Pages, and ever since it's been necessary to make a distinction between ASP.NET Core Razor Pages and ASP.NET Core Proper, which has now been relabeled as ASP.NET Core MVC, making it that much more difficult for people to filter out information on one framework versus another. At least for the time being, Razor Pages are still not as prominent as the MVC-style, and thankfully, they at least don't change much in the core functionality of Core to warrant differing discussions on most things. Long and short, you should pretty much just prefix every search with "asp.net core" (in quotes, so it's done as a phrase search). That will generally always give you relevant information - for the most part.
The next set of issues is that ASP.NET Core was developed with high visibility, fully out in the open and with many, many previews, alphas, betas, and even full releases. On the one hand, that's great and is a large part of why it's as good as it is. Developers were able to provide input and steer the development, making it the first web application framework developed by Microsoft actually designed by and for the people actually in the trenches, building web applications.
The downside, though, is that things changed - a lot - and still do. Though, it now seems to be leveling off pretty well after 2.1, which I consider to be pretty much the first truly feature complete release. However, before we got here, we had ASP.NET vNext, ASP.NET MVC 6, DNX, and then ASP.NET Core 1.0, 1.1, 2.0, and finally 2.1 - all of which fundamentally changed at least how some things work. In other words, even if you confine your searches to ASP.NET Core, there's still a lot of outdated and incorrect information out there, simply because it was written about a previous version and things have changed since. To better your odds, you should consider confining your search to things published within the last year (2018+, 2017 if you can't find anything newer). Any older than that, and you're going to have to take the article with a big, huge grain of salt.
And then that brings us to Entity Framework. Oh my. EF has had a storied history, most of it steeped in failure. The original EF wasn't even viable until version 3. The previous versions were so bad they were literally unusable for any serious production work. Even then, it wasn't until EF 4 that it could really even be consider truly ready for prime time, and finally began having some significant uptake among developers as a result. It was also the release where Code First was finally introduced (technically in 4.1).
Before that time there was what the EF team referred to as Database First or Model First. The only meaningful difference was that one would generate your models from an existing database, while the other would let you design your models and then generate a database from that. In either case, you ended up with a monstrosity called EDMX, an XML beast that attempted to keep up with your database state and all the translation of VB/C# classes to that entails. It was an absolutely nightmare to maintain, almost never worked correctly, and a constant source of frustration.
Code First provided an alternative - a shining light in the darkened pit of EDMX hell. You could use POCOs (plain old class objects) and EF would be able to generate migrations from changes you made to those to update your database accordingly. It could even be used to work with existing databases, though it's name prevented it from being used as much as it should have been in that area (many people wrongly believe that if you had an existing database, you had to continue using the old horrible Database First methodology). In truth, Code First was a complete alternative approach to managing databases, both new and existing. EF 5 and EF 6 continued to refine this new approach, and when it came time to work on EF 7, Microsoft decided it was high time EDMX went to its well-deserved grave.
However, work on EF 7 coincided with the development of ASP.NET Core, which itself spawned off .NET Core and eventually .NET Standard. EF was firmly rooted on the full .NET Framework, so it became apparent that a rewrite was in order. As such, development of EF 7 was cancelled, and EF Core was born. EF Core, though, had a rough ride. ASP.NET Core was moving along like a freight-train, but had no native way to interact with databases. You could use old EF, but then you were forced to target the full .NET Framework, instead of .NET Core. As such, EF Core was rushed to release way too soon, and 1.0 was a train-wreck of epic proportions. There was so much basic functionality missing and the workarounds were so obtuse that virtually no one in their right mind actually would take anything into production with it. Then, 1.1 was release and things improved somewhat but still not enough. Then came 2.0, and finally, it was workable ORM, you could actually feel comfortable using in production. The release of 2.1 has brought even more improvements and refinements.
Now that you've had your history lesson, all I can say is that finding good documentation is still unfortunately a bit of a crap-shoot. You need to be very specific with your searches, using the right terms (which is part of why I wanted to give you the history). You also need to pay close attention to dates. Consider suspect anything that existed before 2017 and treat even stuff from that year with a grain of salt. The official docs are your best friend. Microsoft has actually done a pretty fantastic job with their documentation and keeping it up to date and accurate. It covers the largest majority of things is the ultimate source of truth.
Books are not going to be your friend here. The publication process takes far too long and ASP.NET Core has moved far too fast. Any book on Core is outdated the minute it hits the streets. However, if you have a subscription to Safari Books, you might have luck due to their prelease and alpha offerings there. You have to deal with more technical mistakes, grammatical errors, etc., but at least the information will be closer to the actual truth.
Pluralsight has some truly excellent videos that can help you. Unfortunately, video production has a similar problem as book publication, and there's more than few courses that are now so outdated as to be useless.
Hope this at least gives you some better context and helps improve your ability to source good and accurate information. Honestly, I still struggle myself with that a lot of times, and I think most developers working in this space has the same issue. It's fun and exciting, but it's not without its cons. Having to wade through a sea of information to find some pearls is one of them. Good luck.
