Entity Framework Best Practices - Should EFCore Be Your Data Access of Choice?

Entity Framework is an amazing set of tooling around data access. With EFCore, that tooling becomes even more powerful. So why is it that I still don't recommend that people use EFCore? In this video, I will walk you through the best practices of Entity Framework and EFCore and point out the pitfalls to avoid. We will discuss where there are problems and what to do to resolve those problems.
Mailing List: signup.iamtimcorey.com/
Source Code: leadmagnets.app/?Resource=EFB...
Courses: IAmTimCorey.com/courses
Blog Post: www.iamtimcorey.com/blog/1378...
nvarchar(max) performance: www.sqlservercentral.com/foru...
Downloading SSMS: docs.microsoft.com/en-us/sql/...
C# Mastercourse: iamtimcorey.com/p/c-mastercourse
Thanks to Ralfs HBK for the chapters breakdown:
0:00 - Intro
3:11 - Project setup: ASP. NET Core project
4:39 - Project setup: .NET standard library
6:04 - Project setup: Adding data models
11:02 - Project setup: EF Core SQL server NuGet
13:01 - Project setup: Data Access class
15:26 - EF Configuration: Startup.cs
17:43 - EF Configuration: Connection string
22:46 - Migration scripts and concerns
30:05 - Migration script: Down command
31:50 - Migration script: Up command
37:19 - Multiple migrations
38:46 - Model snapshot...
40:10 - Model snapshot: Nvarchar explained
45:14 - Problem: Nvarchar(max): Indexing
46:49 - Problem: Nvarchar(max): performance
50:52 - ... Model snapshot: why nvarchar(max) ...
52:13 - Problem: EF and data access
53:39 - ... Model snapshot
54:58 - Created Data Base overview
57:50 - Data model optimization...
1:00:48 - Problem: Development vs production
1:03:45 - ... Data model optimization
1:05:18 - Possible data loss with new migration for in production app
1:07:40 - The updated migration script overview
1:09:15 - No data rollback
1:10:39 - Data Base update
1:11:45 - Using the EF: data import from JSON file
1:18:34 - Using the XEventProfiler
1:23:57 - Monitoring and filtering SQL server commands from the EF app
1:27:42 - How the EF inserts data: sp_executesql
1:39:11 - EF query
1:46:39 - EF query: efficiency and possible consequences
1:58:34 - EF query: where clause: SQL vs C#
2:10:40 - Recap: best practices covered in this video
2:12:08 - Why use Entity Framework? Supposed benefits
2:20:12 - Benefits of using Dapper
2:25:46 - Summary and concluding remarks

[@jamesbest3347]

"If the way someone develops a C# application makes you angry, I suggest you reevaluate your priorities in life." LOL legend

[@IAmTimCorey]

lol thanks.

[@jamesbest3347]

@@IAmTimCorey Tim, I also wanted to say I agree with you 100% on your disposition towards Dapper. For smaller applications where you might have a single login that's connected to very minimal amount of user data I believe EntityFramework is a great tool because you don't need to know much about the DB as it's all handled with a model first approach. It's when your small application turns into a larger thing that you realize you wish you were managing this stuff yourself because the migrations start becoming a real hassle and performance can start to decrease. That said, does Dapper have a similar tooling to EF in that it will generate a migration or SQL script to create your DB from the model? Writing queries isn't really an issue for me, but I really do like the model first approach of EF. Thank you!

[@IAmTimCorey]

I haven't found one I liked yet and I'm considering writing one.

[@IAmTimCorey]

The problem with using EF for creating the database is all of the work you need to do to get it right. I recommend SQL Server Data Tools, which give you database source control and automated deployment but are more clear about what they are doing than EF: kzbin.info/www/bejne/n5unlHt9rd6ke5Y

[@JasonDias7]

@@IAmTimCorey yup, that's what we are using. But it forces you to work with Database First, not saying that it's bad. But, there is no good alternative if you want to go Code first

[@GreggBursey]

Man, there are hundreds of videos on “how to EF”, and that’s fine. But your walkthrough here that included not only that, but also the pitfalls, what could cause problems, and WHY those can be problems was extremely helpful. The section explaining the string fields like NVARCHAR(MAX) was very informative and helpful.

[@IAmTimCorey]

I am glad it was so helpful.

[@vkumbaji2010]

Mr.Tim Corey, your courses are superb educational and great resources for learners of all expertise levels.

[@gasparottogui]

Hey Tim, thanks for another great video! I've been learning a lot in your tutorials and it's impressive to see how deeply you understand the language and how clearly you explain it. Thanks for sharing!

[@IAmTimCorey]

You are most welcome. Thanks for the encouragement.

[@GuySymonds1]

Where was this tutorial when I was trying to learn EF so many years ago. Really well made and I love how you show the simple things that are so often missed like where the PackageManager Console is in Visual Studio. I'll be watching a lot more of these videos, keep up the great work.

[@IAmTimCorey]

Awesome!

[@AndrehHimself]

Just passing by to say: THANK YOU TIM! Your videos are awesome and are really helping to move towards a dev career, what you do for the community has granted you a place in heaven. Keep up with such amazing work, cheers!

[@IAmTimCorey]

Glad you like them!

[@metax73]

If all of your other videos are this detailed, I'm going to watch your entire library. I was expecting to to see a couple instances of how to do something in Entity, but this video was so much more valuable then that.

[@IAmTimCorey]

I try to be thorough in everything I teach. It is all about being real-world ready.

[@shanegray8]

Love this. Been making similar arguments for project development for a few years. This is just explained so clearly where now I can just send a link! Good man yourself

[@IAmTimCorey]

Excellent!

[@objectaware5296]

This really doesn't explain anything other than you need to have knowledge and experience with the tools you're using. If you write poorly stored procedures (sp) or if EF does they are still poor. For example, if you don't understand that left joins pull duplicate data and write the sp then you're no better off you lack experience and knowledge. If you understand EF lazy loading then you don't need to pull the data from the address and email tables it will be done for you once the data is needed with EF.

[@larsmagnusnyland9588]

@@objectaware5296 Sometimes lazy loading can be worse than duplicating data, it really depends on which context you use it. If you use it to load thousands of people, then getting all their addresses separately that's good. However, use it in a for-loop to check some requirement for that person, or do some sort of lookup. Not good. This is because a new query is made to the SQL server for each property that is lazily loaded. And using the network card to send a request to a server, and wait for the server to do some processing, then returning a result is way slower than just reading memory. Even if the request takes 5 milliseconds, a thousand iterations on that will be 5 seconds. I'm sorry I have some trauma from when I started working a project that did this, and still does this some places.

[@objectaware5296]

@@larsmagnusnyland9588 Ah so you've gained experience with lazy loading which is my point. Whether I use EF or Dapper if I don't have the experience with the library and SQL Server mistakes can be made. Experience or lack of it is what makes code reviews so valuable. BTW, If I understand the scenario you're describing and know what I'll need in the dataset, I may just use a Function table procedure, done at the SQL server, returning an Entity Dto object.

[@mehedihasanopu5666]

Thank you Tim Corey. It's a great chance for us to learn from your courses. For checking if there is any record in table, Any() functions should be used for better performance. Count() has to read the whole collection of the table but Any() immediately returns after reading a single record.

[@IAmTimCorey]

Thanks for sharing.

[@mhdb96]

Man! your videos always have fully explained satisfying answers to my questions. Keep up the good work

[@IAmTimCorey]

Thank you!

[@salmanahmedazmi3084]

Really well made and I love how you show the simple things that are so often missed.

[@IAmTimCorey]

Thanks!

[@mereblood]

I am SO excited to see you finally covering this topic!

[@IAmTimCorey]

Great!

[@E-Dh]

i am currently using this video as a go to guide whenever a friend of mine mentions using EFCore. Thank you Tim, you really are awesome !

[@IAmTimCorey]

You are welcome.

[@fiqriismail]

Thank you for this great tutorial. Cleared a lots of doubts I had.

[@IAmTimCorey]

Excellent!

[@nussberger]

The first long video on youtube I watched from beginning to end. Worth every minute. Thank you for your hard work, smooth voice, and deep knowledge!

[@IAmTimCorey]

Glad it was helpful!

[@soucianceeqdamrashti8175]

What I love about this video is that you explain each topic with the right level of detail and in a succint and informative manner. Even someone who has primarly used Dapper loved the content and learned a lot.

[@IAmTimCorey]

Excellent!

[@EricHarmon67]

I watched this video with great interest, and I have some comments to make. I have used Entity Framework fairly extensively since EF 4, up until EF Core 2.x. I didn't get a chance to use EF Core 3.x in production, as I retired three months ago. That should give you an indication of my frame of reference as it relates to EF. Anything I see here is, of course, the way *I* worked, and I'm not claiming my way was the best - only that it well worked for me, and in some cases reduces or eliminates some of the areas that you pointed to as causing you some concern. First, I would never allow any data access tool, EF or otherwise, to create the database for me. Though I wasn't a DBA per se, I created multiple databases for use with my applications, and I always created those databases manually in SSMS. Not only did that allow me to define the tables and columns in exactly the way I wanted (for example, I didn't need to know or care whether EF (or nHibernate, etc.) pluralized table names), but I could also create secondary indexes in the "normal" way in SSMS, without needing to learn anything about how EF data annotations (or fluent API) worked for defining indexes and so on. I just think it's better to have complete control over the database structure. The only thing I ever used data annotations for was for required or max length, which allowed the UI to perform validation of data via Validator.ValidateObject(), et al. You showed the long sp_executesql query generated by EF. I actually never encountered that, as that's something new in EF Core 3.x. In EF "Classic" and EF Core 2.x, one insert statement was sent to the database per row insert (and all the inserts were performed in a transaction). It's interesting to note that the EF team got crucified for that approach, as it caused numerous INSERT statements to be sent to SQL Server when bulk inserting. I myself encountered more than one occasion where I saw an order of magnitude or better performance increase when I used EF addons such as EFCore.BulkExtensions and the like, in the few cases where I needed to insert many rows into the database at once. Now that the EF team wrapped the multiple inserts into a single statement, they're again facing criticism. I'm not any kind of security expert, so perhaps there's a better way they could have reached the same end goal, but definitely sending a single SQL statement per inserted row wasn't being happily accepted. I personally never used migrations, as I found them to be too limiting (at least, when I looked at them; it's possible they gained functionality later on). I found that in many cases when I made a database schema change, I needed to do some serious work on the data. For example, I might factor out three columns from one table and two columns from another table and put them into a new table, referenced by both of the original tables. That kind of work didn't lend itself to migrations, so I wrote a little "framework" for database updates, and then whenever I had occasion to update the database, I filled in the guts of the framework with the handcrafted SQL statements that I needed. So I didn't use EF at all for database migrations. I wrote desktop applications, and I was able to completely encapsulate EF into a .NET Standard 2.0 class library, with no reference whatsoever from the UI project(s). This might be different for me because I didn't write web apps (though I'm assuming this would work equally well for a web app), but I got the (encrypted) server name, database name, user id, and password from a local config file, and then passed those to a static method in the data access library, which cached the information. I wrote a UnitOfWork class that encapsulated the DBContext, and the application made calls to UnitOfWork. The UnitOfWork class instantiated the DBContext, using the cached connection information. The main application never knew it was using Entity Framework at all. Finally, I don't think the query where you loaded all people, addresses, and email addresses was a fair one. You wouldn't load them like in reality that unless you planned to do a bunch of updates to all the data and then resave it. Instead, you'd use DTOs and you'd have a projection query, the same as I imagine you'd do when using a different ORM, or when issuing direct SQL statements. I have, though, on occasion done the same thing in EF Core (2.x) that you said you do in Dapper, which is to issue two or more SQL statements independently, and then merge the resulting data using C#. I understand what you're saying about needing to learn EF before using it, but I would argue that that can be said about literally any technology. I wouldn't want to sit down and try to write an application using Dapper (I've never used Dapper before) without studying it fairly extensively. I wouldn't allow Dapper to automatically create the database, just as I wouldn't allow EF, nHibernate, or anything else to create it. So I think that you're being a little bit hard on EF, as it's an incredible data access technology. In my opinion, the types of "gotchas" that you point out relate to any technology, including direct SQL / ADO.NET. I can easily write a horribly performing, though straightforward, query, in direct SQL. For example, I've seen tons of examples that show "SELECT * FROM Customers", which you wouldn't (hopefully) ever do in real life.

[@IAmTimCorey]

I do like that EF passes a big chunk of inserts to the database to process. That definitely is more efficient than individual inserts. The issue is that in order to do that, you have to enable the use of sp_executesql, which can be dangerous. EF does not use it in a dangerous way but the permissions to run that stored procedure have to be on the calling machine, so that opens up the option for someone to call it directly (a danger). As for not using EF until you learn it, I agree that we should learn everything before we use it. My point was that you should be at a much higher level of knowledge before you use it in a real application. The way it is pushed is to use EF when you don't know SQL or if you want easy data access that "just works". That's what I don't like to see. I've cleaned up way to many of those messes.

[@zacboyles1396]

@@IAmTimCorey thanks for your videos. I like to have tutorials and conferences playing off to the side while I work so I can catch good bits. I've been using EF Core 2 and 3 with Azure web and Azure functions deployments but I've never seen a message to reference the UI or any other project. My data is always in an isolated project and the solution builds correctly. Maybe it's something with .Net standard, I've not spent any real time with it. Also, I definitely agree with what you're saying about developers writing their models without annotations however, those same devs would be the ones to use nvarchar(max) using SSMS lol. You're a bit too harsh on EF there. I might even argue that far more EF tutorials use annotations than typical .net tutorials with SQL. Actually, the c# side of those tutorials typically include the constraint information so to demo validation features whereas the database portion is quickly skimmed over. Anyway thanks for all the hard work, hope I didn't come off as negative with the data types, I just wanted to defend EF a bit. I enjoy how thorough your videos are.

[@bonkers_dave]

Eric, this is three months old, so I don't know if anyone is paying attention. I too am a grizzled veteran with years of experience with EF, but I have to disagree with your level of absolutism on things like "I would never allow the data access tool to make the database for me". In the early-ish stages of prototyping and proof-of-concept, especially in the brave new world of micro-services, the code-first cycle with migrations is a huge productivity tool. For a team, you need to establish a process. It used to be that the "prototyping" phase would last a couple of months and then the system life cycle would be five years. But in the era of micro-services, we're prototyping something or other all the time, and there isn't One-Big-Database-In-The-Middle.

[@user-hz1yc6cw6k]

There is one more point against generating database schema from EF annotations: security. To generate database, EF must be connected with credentials allowing to use DML, wich is too high level of permissions in the most of the cases. And, by the way, in ideal world, database design is the job of database developer and security is the job of DBA. But everything today is being outsourced to replaceable masters of nothing and we have to live in the world where students outsourced as "full-stack" senior develovers do everything at once.

[@henrybotha]

@@bonkers_dave Code first with prototyping is a definite win for me. As soon as this goes live or working on existing data, i don't allow my ORM to make changes to the DB. I code them manually in SSMS and manually update my ORM to access the new structure. From my experience, it is much easier to make a mistake with ORM tooling like EF and you destroy a whole DB/table. Its just simpler to apply those permission levels on the DB level and allow the ORM data access only.

[@ioannisstefanou9140]

Hey Tim, great tutorial. I enjoyed the details on where entity framework falls short -- they actually gave a great insight to how this system operates behind the scenes. I would like to propose a suggestion for a tutorial as to how would you implement a repository/unit of work patter on top of entity framework. Thank you for all your hard work. Subscribed

[@IAmTimCorey]

I will add it to the list. Thanks for the suggestion.

[@ignaciolaborde9166]

No, EFC already implements a repository/unit of work pattern, so adding another layer on top is not helpful. You can use the dbcontext directly

[@vkumbaji2010]

Your content and delivery is simply great.. and easy to understand. Thank you so much for the wonderful tutorials.

[@empathetic24671]

Hey Tim, your content not only helped me to understand code and program, but also helped me to see the problems in a completely simple way. Your way of teaching and talking out the solution is unique & simple. Thanks for that.😀

[@IAmTimCorey]

You are welcome.

[@nikoskondylis5618]

Thank you for all your excellent tutorials! One side note I would like to make if I may. The EF design tools can be installed in the EFDataAccessLayer class project. After you install the tools in the class project, make this project as startup project from Visual Studio solution, run your migrations from PM> and switch startup project to UI project when you want to run the application.

[@IAmTimCorey]

Yeah, it is just a pain to do so.

[@get_ready]

Amazing video. I'm pretty new to EFC and total newbie with SQL. I learned a lot from this video, and it made me realize that I should in fact invest more time to learn what I'm working with. Thank you!

[@IAmTimCorey]

Excellent!

[@torrvic1156]

Your lessons are pure gold Mr. Corey! Some things you said I learned the hard way via trial and error myself but other things you advised can’t be underestimated. Such a good advices you are giving to us! You even know about War and Peace book and it tells us as to how knowledgeable and intelligent you are. I am amazed by your charming personality Tim! Thank you so much!

[@fabiajero]

You are the best programming teacher I've ever met. Thank you so much for this content.

[@IAmTimCorey]

Thank you!

[@greenwalmart]

Tim, you did an great job covering this topic. I try to tell people that programming is the last thing that you do. And your videos demonstrate this. You have to know exactly what you're doing or pay the price on the backend. Awesome video!

[@IAmTimCorey]

Thank you!

[@TheMaKasss]

I knew everything you said. But still good to know, that there are such a good tutorial for people who interested in what they are doing. Good job.

[@IAmTimCorey]

Thanks!

[@drapp5752]

Tim, thanks for the videos, keeping them short and direct to one aspect at a time. Especially the initial going with the established connection to the database getting all else started in place. I have been doing the hard grunt work of CRUD with parameterized SQL commands but thought I might as well try to learn new (even though near retirement and not a big deal, just like to learn). I do see the much lighter implementation than SqlCommand, SqlParameters, SqlConnection and building out queries, but much of what I do also deals with dynamically prepared and filterable queries for getting data and just know that it COULD be done, just not changing over existing work, just looking to the future. I also notice you doing hard-reference object names to get to the form's objects and such. However, do you also have experience using MVVM patterns and bindings such as text to a property object instance. I find that approach works nicely in that you dont have to know what the controls are on the form, you just look at the model's properties to act on for values. You dont have to care about what the forms object name is to get them. And if some values are numeric based, and bound to a textbox control, you dont have to think about a valid value as anything invalid as number is just zero. Just a comment though would be an additional level of confusion to those try trying to understand the basic flow operation you have provided so well and completely get the point across. Enjoyed all the videos.

[@parthbhagwat7975]

Thank you!! Ton of information in a single video. You highlighting multiple times about issues in production hit the chord with me. Hope you have/do some videos on memory leakage and exception handling.

[@IAmTimCorey]

Glad it was helpful!

[@TehDarkWolf]

I feel like it's still important to learn it for people who are planning to get into professional industry. EF is widely used in many companies ranging from small to large, I honestly I have heard of dapper until I came across your channel. The best way to learn is to use the frameworks, if you consistently avoid well-known frameworks you won't really grow as a developer and limit yourself in the professional world.

[@IAmTimCorey]

True. You will face it so you should learn to do it right. I would recommend learning it later on in your C# development training. In my Foundation in C# course series, I teach it in module 8 (out of 10): www.iamtimcorey.com/p/complete-foundation-in-c-course-series

[@objectaware5296]

I agree. Most MS Stack shops use EF but you should have a good knowledge of SQL and Database design, in most orgs, you're the DBA. If the shop does not have formal code review, find the most knowledgable people in each discipline and ask them to review your code. You'll learn something most times.

[@joeyf9826]

Try as we might, I don’t know if we’ll ever abstract away from the details of how DBs work. EF is somewhere in the middle of the abstraction, where it tries to hide the DB details but will also burn you if you don’t know what SQL is being executed. All too easy to write a query that ends up pulling a million rows into memory.

[@alanskaev]

This video is so detailed and thorough it shouldn't even be free

[@IAmTimCorey]

Thanks!

[@UnknownMoses]

No it should not be free.

[@bengardiner5880]

@@UnknownMoses i mean im quite happy is free

[@imanqoly]

Totally agree with you

[@Thespartanassassin1]

I've been looking a lot of ef guides. I also have prior experience with it but never created a project from scratch myself, this guide is absolutely the best one I've found so far. Superb job and the flow you have is absolutelt great! Thanks a lot you saved me a lot of research time

[@IAmTimCorey]

Awesome! Glad I could help!

[@JonWood]

These videos are great! I just like to have them running so I can pick up on all the tidbits you mention. Great stuff!

[@IAmTimCorey]

Thanks!

[@tchpowdog]

I agree with everything your saying here in regards to having to be experienced in order to use EF efficiently. However, everything you laid out is from a "code-first" perspective. I use EF in all my projects, but I don't use their migration and schema tooling. I use good-ole fashioned DB-first approach. I use SSMS as much as I use Visual Studio. Also, I only use EF for entity level CRUD operations and very basic queries. If I have ANY more-than-basic queries or data logic, I use SPs, Views, Functions, etc. - then I call those functions through EF. I wouldn't recommend using EF for a code-first approach, either. However, I wouldn't recommend code-first AT ALL. Personally, I despise the code-first approach - but I also appreciate the fact that it works for other people.

[@IAmTimCorey]

Yeah, I think the big takeaway is to be careful and know what you are doing really well. Code First, which is the method that is most often pushed, can be done well if you are careful but if you aren't, you can create a mess.

[@LiganPL2]

I have the same opinion as you. In my company it looks the same as you explained. We never used code-first model.

[@znk0r]

Curious to know a bit more about what makes you despise code first. We had a team discussion before starting a second code first project and we mostly agreed we liked the fact that devs could focus on what made sense in code and have the ability to refactor without having to create the schema updates themselves. Yes you have to handle the data updates and merging stuff between branches but we still felt it was worth it. It wasnt 100% unanimous so outside opinions are interesting.

[@tchpowdog]

@@znk0r I just like the database first mentality. I am a systems architect and I build web applications, pretty much only web. SQL and Oracle are incredibly powerful and I feel they are under-used with a code-first approach. I believe one's first intuition should be to place logic in the database via SPs, Functions, etc (of course this isn't always the right thing to do). Being database first also aligns with my system architecture philosophy, which is: Lightweight Web API that scales horizontally Heavy database that scales vertically Fast front-end framework (Angular or React) I understand there are trade-offs either way and a lot of it depends on the application. I guess the thought of a programmer creating a database without much knowledge of databases scares me, so I'd just assume not go there lol For example, I hired a brilliant programmer about two years ago and he has done a great job, but he never learned SQL or Oracle in school. That's scary to me. When you reach scale, you can put yourself way behind by running into severe performance issues if you don't know how databases work. But like I said, I do appreciate the fact that it works well for others.

[@timetorelax45]

@@tchpowdog I have similar background as yours and we used to despise database queries being programmed inefficiently in the application layer by people who seemed to not care too much about database design. So, we improved up on that by moving database related to sp and functions. Gave us so much more control and flexibility. Having said that, I recently started using code first ef core and I love that I have all my logic in one place, however I am careful with it and use it efficiently by keeping an eye on how things work under the hood. I agree it can go bad if done by people who know little or care less about databases.

[@lolop2576]

I consider myself a pretty experienced EF developer, but had only just learnt about the drawback of using Includes from this video. I had assumed it did something along the lines of QueryMultiple in Dapper. Just shows it's always worth looking at videos on topics you consider yourself well versed in. One thing I was waiting for you to bring up was projections. Using Select statements is an extremely important part of making sure that EF runs smoothly for me. It solves the issue of Include, and removes the change tracking which is another big cause of slowdowns. Using projections you can get near identical performance to Dapper, while also keeping all the benefits of EF core. One of the most important things for me is the compile time safety of my queries. Admittedly I haven't watched your videos on how you use Dapper yet so I'm not sure if you've addressed this. I also think using the right tool for the job is an important aspect. If a query is complex and needs to be hand crafted for performance, writing the SQL manually and using dapper is the better option. If you just want to pull a few fields from a table or two and put it into a VM/DTO, I think EF with projections is usually better. I'm not against using both in the same project and using EF for 90% of my needs, and Dapper for the last 10% of more tricky/important aspects of the application. Lastly, in case you didn't know, you should be able to change the 'Logging.LogLevel.Microsoft' in the appsetting.json to be 'Information' and all the queries run by EF core will be logged to the ASP.net console. I find it much easier to look at the queries as they go through there than trying to filter through the junk in SQL Management Studio. Just my 2 cents, great informational video overall, especially for newer developers!

[@IAmTimCorey]

Yeah, I just touched on some of the topics. There is a lot to cover. I'm glad you enjoyed the video.

[@dzllz]

Great points. Select solves the issues of include

[@absentbrainded]

This was really helpful for me TIm. I really appreciate the careful and balanced presentation on the topic. I'm an experienced SQL developer, but brand new to EF and C#. Many of the topics in this video were eye opening for me. I'm not sure if I'll have the ability to use Dapper on this client project, but you helped me at least be well aware of some of the biggest pitfalls to avoid.

[@IAmTimCorey]

I am glad it was so helpful.

[@BryanPollardPhotos]

Thanks Tim! I wish I had this a couple years ago to share with my junior developers. I have had the same reservations as you for many years about ORMs in general. I have seen them totally derail an application once it hit production. My team used EF for the first time a couple years ago and I have been fairly happy with it, but this video pretty much sums up my feelings about it. As a hiring manager, it has been a challenge to find newer developers that can work "without the net" of an ORM. I believe that knowing how to do both is critical to being an experienced developer.

[@IAmTimCorey]

Thank for sharing from that perspective. Appreciate!

[@Hekmat222]

Hummmm, in my whole development life this is the first time to see this type amazing explanation. Great job.

[@IAmTimCorey]

Thank you!

[@Hekmat222]

@@IAmTimCorey now you are our instructor, I have learned much techniques from your best tutorials.

[@Guacamole42]

Awesome video! Thank you for making this one. I like EF very much. It hides the database mechanics once you have set it up correctly but when you get a problem later on, good luck with that. Great teachings coming from you about EF, I love it!

[@IAmTimCorey]

Thank you!

[@keithnicholas]

when you say "hide database mechanics" you need to be careful, it implies you're encapsulating this lower level thing. But that's not what is happening, what is happening is you are hiding stuff you don't want to have to think about. Which is fine, it can simplify things. But what you are hiding is actually a much much richer higher level system for dealing with relational data. You are dumbing things down and bridging it into the C# world where you can deal with data in a more restricted way.

[@jhtaljaard]

A video of this quality is rare - thank you so much for this. I also learnt a lot from it. Well constructed and very clear. Thanks for covering some of the pitfalls and nuances. :)

[@tomthelestaff-iamtimcorey7597]

Thanks for watching and promoting Tim's videos.

[@CodeYourselfToDeath]

Dude your tutorials and calm and collected explanations are top notch. For real if you like this youtube thing, don't give up on it. You make excellent videos!

[@IAmTimCorey]

Thank you!

[@gedwistle1974]

Not sure if this has been addressed in comments already, but for your first issue about having to reference EntityFrameworkCore from the web app in order to call services.AddDbContext, you can simply reverse the dependency. I use a static method on my Context partial class that takes the IServiceCollection as a parameter. This allowed me to remove the reference to EntityFramework from my web app project all together.

[@IAmTimCorey]

Thanks for sharing.

[@idis5702]

you can use Iqueryable method for where clause, like predicatebuilder that is functional and also it is easy to use

[@IAmTimCorey]

Can you show me an example of what you mean? I'm not quite understanding what you are saying.

[@Doomchild_]

@@IAmTimCorey I would change the return type of the ApprovedAge method from bool to Expression and return x => x.Age >= 18 && x.Age

[@jawandsingh1464]

Thanks a ton, Tim. I loved the way you showcased the little things we always miss.

[@IAmTimCorey]

You are welcome.

[@henriquemartinsdesouza6527]

Hi Tim ! Thanks for share part of your knowledge with us, it's been a pleasure to apply my free time learning with your videos! Just a suggestions: Maybe it would be nice if in the videos' descriptions have some kind of summary about in what time in the video that topic will be discussed.. anyway just a suggestion, thanks a lot for your work!

[@IAmTimCorey]

Yep, that would be nice and it is something I would like to add. It just takes time and it hasn't been high on my priority list yet.

[@sufyaniqbal8939]

This One lecture is better then my half semester in uni. Thank you so much for your kind effort ❤️ Love from #Pakistan

[@IAmTimCorey]

You are most welcome. Thanks for watching.

[@sufyaniqbal8939]

@@IAmTimCorey I really appreciate your work. Keep it more and more. I will try to invite my friends too. come and learn your advance level concepts.

[@MohammadKhanfer]

Hi Tim, we are selling a white labeling product for many clients, each one of them has a totally different application & database version. One of the major benefits that we have in EF, as you said the tooling is great in EF, so we are using it to manage Migrations and to generate it, also we integrated that with our CI/CD so all DBs automatically using the same tooling. What is the better alternative here? What about doing CQRS and using EF for write operations at least to make things faster in development. And thank you for the great video.

[@IAmTimCorey]

It really depends on your situation. Again, if you are an expert at EF and are careful with it, it can be an amazing tool. You can use SQL Server Data Tools to manage migrations and CI/CD right in Visual Studio ( kzbin.info/www/bejne/n5unlHt9rd6ke5Y ) and then use Dapper for data access. It just depends on the situation, the team, etc.

[@henrybotha]

Geat video, thank you tim for taking the time to make these!

[@IAmTimCorey]

You are welcome.

[@ronelperez7201]

Thank you So much Tim. Everything is well explained and clear all throughout! More videos like these please!

[@IAmTimCorey]

You are welcome.

[@rakip3188]

Small correction: Ascii has 256 characters Unicode has 143,859 characters Thank you Tim for your hardwork in putting these videos together. Greatly appreciated 🙏

[@akuskus]

And even smaller correction: ASCII is written in all capital letters.

[@ahmedifhaam7266]

@@akuskus that's not really a correction of data, just convention, OP actually gave a correction by providing new facts.

[@akuskus]

@@ahmedifhaam7266 true

[@anubhavdebnath2747]

small correction ASCII should be written in all capital

[@qutiephoebe2154]

You dont find these best practices and tips from other videos... They just teach you how to write code... That explanation and difference on approved age in the where clause is bravo!👏👏👍👍

[@IAmTimCorey]

Thank you. That's what I attempt to do with all of my videos.

[@StudentCompanion]

Looking forward to watch this video. One of the confusing subject I have faced with seemingly no escape route.

[@IAmTimCorey]

I hope it clears things up for you.

[@gavranhas]

That was amazing, Tim. Thank you very much for all the work you have to put this explanation up.

[@IAmTimCorey]

You are welcome.

[@zoltan.halasz]

Simple, clear, easy to follow lesson on this important topic.

[@IAmTimCorey]

Thank you!

[@tmfink10]

Hi, Tim. I'm wondering if you've been keeping tabs on the development of EF Core. If so, do you feel they have made any significant improvements since you produced this video that would address any of your core concerns? Or, do you feel that any progress has been made in other areas that could help to offset any of your concerns?

[@jasonargo9085]

Probably not considering I just created a new VS2019 project with EF Core and all of the configurations are still present as they were when this video was uploaded, including all the nvarchar(max) nonsense

[@markippo]

@@jasonargo9085 tbh how do you expect them to be any different? How autogenrated code should know your sql string precision if it's not set? Nvarchar(max) is of course very inefficient approach, but quite wise as long as information is not given. If characters are less than 4k, it performes as varchar, if length is exceeded, it is converted to text. Entity Framework or any ORM systems aren't the problem, people are and their thinking that orm realeses them from knowing sql. No... If you wanna go abstract, you've got to know the foundation of the abstraction, otherwise you'll end up like all of them - whining about inefficienies, deadlocks etc. Want to work with relational databases, you've got to learn sql. Period.

[@jasonargo9085]

@@markippo Yes, I wrote that comment at a time when I knew a lot less about the subject than I do now. Most of that comment was me probably trying to figure out what tools I wanted to learn

[@davestorm6718]

@@markippo - I've found that EF is too "black box" for my tastes. But then again, I come from a database first (and have for 20 years) approach to applications, and it's never been an issue for me. Also, when I see code-first implementations, it appears that you end up having to muck about the database anyway (not to mention security issues, the ridiculous number of superfluous calls made to the database by EF, etc). This and, honestly, how often do you change your database to a completely new system? In 2 decades, I've only seen it done once, but then again, the ENTIRE stack was changed from DotNet/SQLServer to LAMP (and it was, to say the least, the dumbest move I've ever seen a company do, all because some idiot didn't want to pay a few grand for SQL Server - they blew a million bucks in labor to save a few grand).

[@frankolee4892]

I found Tim's video incredibly useful and it did a fantastic job at highlighting issues. I don't know if this is a new feature or perhaps I missed... but I found that EF would not run a migration which would cause a truncation of a string (and hence data loss) via Update-Database in Package manage console, and would throw error when attempting to apply migration at runtime (docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/applying?tabs=dotnet-core-cli) This was discovered while playing around, I haven't read the docs so can't confirm how safe this safety net is! Check for yourselves before risking it on production data!

[@InsolentDrummer]

The reason I find Tim's channel so useful is because he always explains why we do certain things one way and not the other and not just because he said so!

[@IAmTimCorey]

Thanks!

[@jimthompson1772]

Tim - Great video!! I've never really used EF primarily because it seemed more prudent to separate UI. models and the underlying storage. Your video confirmed that decision. I tend to lean on using SPs for nearly 100% of DB access using parameterized SPs and SQL. There is something comforting about being able to change an SP to impact performance and results without having to rebuild and re-deploy code. .. Thanks!!

[@IAmTimCorey]

Glad it was helpful!

[@RyomaGG]

16:58 You can put in an override for OnConfiguring in the PeopleContext class protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { base.OnConfiguring(optionsBuilder); optionsBuilder.UseSqlServer(Configuration["ConntectionStrings:YourConnection"]); } Therefore your front end no longer knows about entity in this circumstance.

[@milanpospisil8024]

Yes, there are many techniques that can do that.

[@tomthelestaff-iamtimcorey7597]

Thanks for sharing the tip!

[@leeanderson9486]

This is exactly how I felt about EF. It’s analogous to a piano, press all the white keys, ooh this is easy but… The slickness of the tooling doesn’t give the developer enough of a heads up toward the power it wields under the hood and only an advanced developer would be able to infer/reverse engineer it from an inherent understanding of SQL server / db design.

[@dimitriszafeiris6380]

Hey Tim, i would like to thank you personally because you have done great video work...I really understand everything that you explain in video. I have just started a few months ago a coding bootcamp and your videos are extremely helpful. Well done. I wish you everything best!!!!

[@IAmTimCorey]

You are welcome.

[@ankuronlyu]

Thanks Tim for this nice video, we are already using EF Core in production and in the beginning we got some performance issue but now we have optimized the LINQ query.

[@IAmTimCorey]

Keep those skills up. More issues will come up, so knowing how to debug performance and improve it will be critical.

[@chadwad12]

I'm watching this video as a long time user of Entity Framework (before EFCore was a thing) and as someone who successfully uses Entity Framework Core on enterprise applications that has a lot of data. I wanted to bring up a quick note though of you talking about that you "hate" how EF could technically expose your DB Credentials if you developed it on a desktop application. While that is true, I could make that argument for any desktop application that connects directly to a database. You even mentioned it in the video, that the user technically owns that one part. Any desktop application that connects directly to a database will have to somehow put username and password on the users system. Be it encrypted (and you said it, user technically owns one part of that key) and compiled into the code, it's still possible for me to mess around find it. While there are pros and cons I myself would most of the time develop a desktop application to talk to a mediator, like some kind of web API. I can manage access easier that way and can manage what is actually going in and out of my database. I could even develop some type of cache before it gets to the database, but that is whole different topic. So for most systems I end up building some mediator to talk to a desktop application, unless I am building like an offline only application. Then at that point if the user wants to "hack around" on the local db it talks to then go right ahead. So for me I guess I just don't think it's fair to just really talk about EF there. I feel any desktop application that connects directly to some remote database can have that issue, no matter what you are really using at the data access layer.

[@erikverboom5383]

My thoughts exactly! I loved the video, very educational. But as far as I'm concerned the tone could've just as easily been something like: "You want to use EF? That's cool, but this is what you need to be aware of!"

[@IAmTimCorey]

I agree with you but I think you missed one key piece of my argument about the credentials. It wasn't just that the credentials are exposed (as they are with any desktop application, as you pointed out). It is the level of permissions those credentials need to have. They need to have essentially full administrative access. They need to be able to directly access tables for read and write, they need to be able to create and drop objects, and more. If you use an ORM like Dapper, you more easily have the option of only allowing stored procedure access to your database (I know you could technically do this with EF but at that point it is a lot of overhead for essentially just...Dapper). So even though the credentials are exposed, they only expose what the application already allows them to do and not really anything extra. Sure, if you didn't allow regular users access to a stored procedure they might be able to call it directly using the credentials but that is a whole lot less than being able to run "drop table" or "delete from" commands. I definitely agree about the middle layer (or mediator, as you called it) like an API. I actually use that technique in my TimCo Retail Manager series. That does eliminate that particular issue (well, 98% at least).

[@codefoxtrot]

As of EF Core 5.0, Split Queries have been introduced to solve the cartesian explosion problem that was described in this video. This feature significantly improves single query performance, and I was happy to see it! Granted this does not solve the fundamental problem that by default, it's easy for a newbie dev to get into trouble, which is your point. Especially when I tell you Split Queries, which can be enabled globally, is by default turned off! But nevertheless, for those of us that are experienced and read documentation, EF is now extremely viable.

[@IAmTimCorey]

Yep, that's a great feature. You are right that it doesn't solve the new developer issue but having that option is really important.

[@Hamza-Shreef]

Well i used to do explicit loading to solve it , don't really know if they have such feature thank you bro

[@parveensharma9806]

Hey Tim, thanks for another great video! I've been learning a lot from these. The main point which I want to mention is, you just explain each question before I think I need to ask :) and it's impressive to see how clearly you explain it. Thanks for sharing! Your dedicated student :) :)

[@IAmTimCorey]

I am glad it is helpful.

[@timrobertson8242]

Another Awesome real world explanation. Even the preamble with the ground rules on commenting and disclaimer that everyone can have a valid opinion - priceless! Fortunately, it looks like I’m coming to the party at just the right time for .NET and learning C#. I’m working on a transition with a friend from a PowerBuilder based product to work through what makes sense to move to C# and .NET Core (for the computational / Data crunching part of the solution). You’re content has rapidly gotten me oriented and confident about iterating through a solution. Thank you again! -even more: You’re example right at the start is a Person with multiple addresses and emails - Real World requirement - and an explanation that communicates and causes the viewer to “think” but still simple enough to keep engagement. Wow!

[@tomthelestaff-iamtimcorey7597]

Thanks for growing your skills with Tim thru this video.

[@torrvic1156]

Tim also knows about War and Peace book! It is astonishing by itself. He is not just a great programmer and teacher but he is a man of culture also.

[@Clrscr112]

To be honest EF most of the time is fast enough. Emphasis on the enough and not the fast. We have a fairly large system backed up by EF6 and users never mentionted anything about poor performance but to be fair we made precautions and optimised the performance heavier parts. For us the faster development outweights the performance penalty which is not a real issue (at least for us).

[@IAmTimCorey]

Yep, it all depends on circumstances. The danger will be if you get acquired and take on a large number of new clients. That can be an issue (I've seen this happen to clients). The good thing is, like you said, you've optimized the heavy parts. That goes a long way.

[@andrewelmendorf2602]

Same here. I have 3 fairly large databases accessed with apps using ef core and would have a hard time justifying a switch for any new projects(just started another with ef core).

[@acoupe1970]

I find that data annotations are essential for getting more control on creating a model and they are easy to understand

[@IAmTimCorey]

That's good.

[@aminebenhebba1891]

I personally hate them (in general I hate anything that pollute any abstract or higher concept like Entities just for some details) prefer using Fluent API with overriding onModelCreation method and pointing to mapping classes for my entites implimenting IEntityTypeConfiguration interface. I find it cleaner and better practice. As uncle bob said : jumping from higher concept to lower ones in the same line of code is just a rude code to write. A bit like this on the PeopleContext class : protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.ApplyConfiguration(new PersonEntityConfig()); modelBuilder.ApplyConfiguration(new AddressEntityConfig()); modelBuilder.ApplyConfiguration(new EmailEntityConfig()); base.OnModelCreating(modelBuilder); }

[@aliaksandrbortnik1874]

FluentAPI gives more control than DataAnnotations. However, for stuff like simple constraints and limits, for instance, required, length and some more I prefer to use annotations to keep them right together with Entity class. It becomes reasonable in cases where there are 10+ entities in your DB.

[@acoupe1970]

Aliaksandr Bortnik I quite agree with you there, Fluent is very useful in that situation

[@abdulraufjutt1791]

That's incredible, thank you so much to tell these darkest part of entity framework this information help me to understand that nothing is perfect you do have to go in deep to find out how the things really working.

[@IAmTimCorey]

You are welcome.

[@lechklimczak3976]

Thank you for this excellent tutorial. Best video I have ever watched on EF.

[@IAmTimCorey]

You are most welcome. Thanks for watching.

[@lenardbartha6722]

I like EF Core, much more than EF 6. Version 3.1 is a great improvement, just waiting for the documentation guys to catch up since the docs are still on 3.0. I think because MS is so invested in it, it has a large community and support, which is a big plus.

[@IAmTimCorey]

It has come a long way.

[@roodborstkalf9664]

They have only five or six people working on the Entity Framework team. That is not very invested in my opinion.

[@lenardbartha6722]

@@roodborstkalf9664 On github, the shows 181 contributors. Now I know not all are Microsoft employees, how do you how many are on the team? Where did you get the 5-6 people?

[@roodborstkalf9664]

@@lenardbartha6722 : They said this themselves somewhere on their github pages where they were discussing what things to prioritize.

[@lenardbartha6722]

@@roodborstkalf9664 Hmm, that is good to know.

[@Namynnuz]

1:14:30 instead of .Count() == 0 it's better use .Any().

[@IAmTimCorey]

Why? The SQL command it runs is the most efficient command it can run. Is there a different benefit?

[@Namynnuz]

@@IAmTimCorey that's a better practice with LINQ overall, because implicitly it should result the same thing. But, there's difference in LINQ implementation and .Count() is kinda slow operation. I'm aware that EF mapping LINQ to actual SQL querries, but it also should convert .Any() to correct SQL form (similar to yours, which is .Count() == 0). But in every other places, it's just a better practice overall. So, to maintain consistency.

[@IAmTimCorey]

Ah, gotcha. Thanks for sharing!

[@JasonDias7]

When you use Any(). executed sql looks like this SELECT CASE WHEN EXISTS ( SELECT 1 FROM [Person] AS [e]) THEN CAST(1 AS bit) ELSE CAST(0 AS bit) END

[@silverbane0069]

I wrote an extension method that would return true/false based on a Take(1) based on the where clause, this was a few years ago, but in my testing on a decent amount of data, it performed way better on the large datasets I was working on, since it was stopping as soon as it got the first record as opposed to looking at the entire dataset.

[@luiszabala4964]

The best tutorial about EF I have ever seen😍🔥🔥🔥🔥🔥 thanks Tim

[@IAmTimCorey]

Wow, thanks!

[@Max34Mtp]

Hi Tim, First of all thank you for this video and for all videos posted on your channel. All very reliable content. I watched your video because I asked a company to rewrite for Windows platform an old application I inherited. They came back with a windows forms, C# and EF solution. I am now in charge of the maintenance of the application and as DB designer and with very good knowledge of SQL I am always skeptical with all these frameworks. In past life I was also maintaining a Java/hibernate web site. I must admit that EF seems to generate a correct SQL query than hibernate 5 years ago ( perhaps it has improve since then). To be noted that the database is well normalized, not fully obviously. So as a DB manager I am sometime frustrated by the fact that I could have wrote a better more efficient query than EF. But EF and mapping tool are quite good in facilitating integrating between code and dB. Nevertheless in my case I have to customize and add some specific features in the EF part to manage update of object as well as other trigger in backend to ensure that my data are correct and can be exchanged. And this aspect is quite a nightmare from now. Perhaps for editing data is better to use classical DB direct Access and for viewing DB data to rely on EF for faster development. Anyway thank you for sharing your knowledge. Max

[@IAmTimCorey]

Thanks for sharing.

[@Usernameiswadum]

Wow, this is an amazing video! We were taught to use EntityFramework Core at my university, but they did not mention ANY of these huge drawbacks and how to overcome them.

[@IAmTimCorey]

I'm not surprised. People often tend to gloss over them when evaluating EF.

[@joeyf9826]

Thank you for this video Tim. I wish I had seen it earlier as you mentioned some great points. EF is (too) good at hiding what does and does not get translated to SQL, even when there are huge performance implications.

[@IAmTimCorey]

I am glad it was helpful.

[@Spinikar]

Thanks for the video Tim. We use Entity Framework a lot in our in house software, work in an internal software dev team. I'm still new to C#, .NET, come mostly from a Front end, JS development so this has helped me to understand that EF is not as simple as it appears with the hidden dangers. I still need to use it as that's what our projects are running but this has helped me to take it a bit slower and really think about what I'm doing. Thanks!

[@IAmTimCorey]

I am glad it was helpful.

[@justtohide]

While I didn't know about this channel, when I was trying to write migrations from other channels, no one went that deep, they didn't show the errors, and so I had a problem every time I found a problem myself. in the end, I lost my enthusiasm and instead of writing with migration, I switched to writing db first. when I discovered this channel, everything was great. Thanks

[@IAmTimCorey]

I am glad it was helpful.

[@ChristopherSalisburySalz]

Very thorough!! Thanks, Tim!! Lots of good information for data access in general. I also learned some new debugging techniques! I didn't know you can pin values in the Locals window - pretty cool!

[@IAmTimCorey]

Glad it was helpful!

[@elenafartukova1656]

Hi Tim, thank you for the great video! Every minute is worth watching!

[@IAmTimCorey]

You are welcome.

[@edanielsen]

Thanks @IAmTimCorey, this is great. I have a lot of experience with other languages but now need to use C#/.Net and EntityFramework for an upcoming project and this video has been awesome. Because of the amount of experience I have with Hibernate/JPA and ORMs in other languages it's relatively easy to pick up but you're pointing out some very interesting details here which are easily overlooked. Very much appreciated, your material will get a strong recommendation from me!

[@IAmTimCorey]

You are welcome.

[@soarwing52]

went through the whole video and do along with it. I'm deciding whether use Dapper or EF Core in this moment, the deep analysis made a long video never felt long, all information is really valuable. thank you!

[@IAmTimCorey]

Glad it was helpful!

[@patrickbodin1299]

Tim, I really appreciate your 'real world' dialogue. So many people in dev world want to make their projects a 'rube goldberg machine'. All of our organizations need simple, fast and operational. I'm somewhat proficient at ADO (SG alumni). My goal is rapid provisioning of applications, I'm very comfortable with SQL and prefer the flexibility of sprocs to provide results to c#, happy to use Linq with those results. I'm not an expert by any means at EF, but I do love what MS has done with EF Identity (ready to rock out of the box) in ASP MVC. I have 2 questions, where do I invested my limited (def finite) brain power to achieve faster development? Where I can find those resources? I'm querying your site now. Thank you!

[@kunststofffantastisch5690]

Brilliant tutorial!!! This should be a standard tute for anyone starting out in development with netcore etc.

[@IAmTimCorey]

Thanks!

[@geekverve]

This is a fantastic video. The number one anxiety point of moving our legacy applications to a web app has been my understanding that I literally knew enough about Entity Framework to be dangerous. The mere thought of applying database migrations as the project progressed into production with continued development was terrifying. You've provided much of the information I need to navigate that particular mine field. You've also got me considering Dapper, instead.

[@IAmTimCorey]

Excellent!

[@bobpond6381]

Just discovered your channel. I like that for this topic you got right into using SQL profiler to see what EF is doing. Learning how to make EF do something close to what you would write by hand is a key ability to pick up, DDL and DML both. You do a good job of giving people the info they need to start down that road. As commented EF gives you many ways to shoot off your toes but people can also write some pretty scary SQL queries out of ignorance as well. Loading child collections manually is pretty easy, I rarely use .Include directly.

[@IAmTimCorey]

Thanks for sharing and welcome to the community. We are glad to have you engaging.

[@JabmarMusic]

Your's course not only explains how to build a program in Visual Studio but also is a great lesson of how to speak in english. Big thanks.

[@IAmTimCorey]

You are very welcome!

[@vanilsonnog]

First of all, great video! Had me thinking about the EF Core Linq-to-entities queries I've been making on my projects lately and I'm gonna review those again, now that you explained in details those potential problems. Another thing that I'd like to point out here as one of the downside of EF Core, at least in my point of view: you have to know so much to be able to update records in the database. You have to know about how to attach entities, how to manipulate states (EntityEntry().IsModified for example), about Local and how to check and use it, one-to-many record dependencies... the list is so vast! I understand that the user has full control about EF's tracking system, but it causes so, so much confusion! I've been struggling to make it work. You absolutely have to be an advanced developer in terms of EF if you want to make use of the tool correctly.

[@christopher19843]

Adding, Updating, and Deleting is very easy using EF.

[@WeijieJIN]

Hi Tim, thanks for the video! I don't like the code first approach just the same reason you demoed in the video. So in our projects, we use db first. And we do the revision control though the scripts, similar like flyway. I am glad that we avoided most of the pitfalls in the video. I think the benefit of EFCore is that after you knowing how EFCore works (although you might spend some time to learn), it's quite productive, and since it's ORM, it can keep the code base quite clean (again, we don't use code first:) this is important). Although dapper also has things like simpleCRUD, but you need do more stuff when handling for example, many to many scenario. In conclusion, learn EFCore well then it will be quite benefit. Thanks!

[@IAmTimCorey]

It all depends on where you want to do the work. I'd rather write a SQL script rather than verifying the design of each query and the performance implications of it.

[@BerrisGaming]

Thanks a lot! I've watched the whole video and there is one thing I would like to mention. I am a EF user (haven't used Dapper) and you talked about optimalisation. In the part where you showed the `Include` and what the differences where you forgot to mention repositories. You went in to quite some detail on optimalisation in data storage, and memory usage for queries. But without repositories who will handle getting data efficiently it is fair to say that EF is not optimal for production. Of course we could populate the lists manually in C# without using the Include, but this would be ~10 lines of code everywhere in our application where we wanted to get people. So that is why explaining repositories in a "best practices" guide would be fair. English is not my primary language so it might come off a little bit negative, which is not what I'm trying to enforce here :D Thanks for the explanation I learned some new things!

[@IAmTimCorey]

Good point. Thanks for sharing.

[@nventexdba2741]

Great video btw! I've used both EFCore and Dapper depending on the project. With EFCore the MS.EFC.Tools library for migration works great, but with Dapper I use Roundhouse. Would like to know what you are using for database migrations when you use Dapper. Thanks for all the great content!

[@IAmTimCorey]

I use SQL Server Data Tools, which is a Microsoft-provided project type: kzbin.info/www/bejne/n5unlHt9rd6ke5Y

[@ashraflambe]

Hi Tim, thank you for great job towards C#. I was thinking that this language is losing market ground. But now with your detailed videos I changed my mind and came back. Thank you again.

[@tomthelestaff-iamtimcorey7597]

Welcome back and thanks for trusting Tim for growing your skills.

[@tonyocnos6691]

This video is just gold. I was told many times about the EF/EFCore upsides but I was always wondering about all those downsides that probably were hiding behind the scene. And here we are! Thanks Tim! P.S.: I requested the code for this video but it was never sent to my email :( .

[@IAmTimCorey]

I'm glad you found it valuable. As for getting the source code, check your spam filter. If it isn't there, email [e-mail] with which video you are missing the code for and we will get it to you.

[@liranbarnes5593]

Hi Tim Thank you for this video. I really enjoyed watching this content. And it really gave me insight into some of the things I took for granted, and I didn't check them and I had to check. Since I don't know Dapper, I'll check it out soon. I still think we can write the database in SQL and then load it through Entity framwork and then enjoy the benefits of using it with little code .

[@IAmTimCorey]

I'm glad the video was able to improve your process a bit.

[@quantum634]

Thank you for this tutorial... its easier than I thought. Also thank you for showing us the "dark" side of EF. I will watch out when doing my queries. In the worst case I will just write a SQL query. Tbh I even prefer writing them instead of figuring out how EF creates them... but for quick and small stuff I think its fine.

[@IAmTimCorey]

You are welcome.

[@peadenl]

Another great video Tim. I have limited experience with EF but you are 100% correct about how it will kill you in production. Also the developers will be clueless on how to fix it when you ask them why their application is running such idiotic queries. You have to try to fix issues by creating indexes and harass them to purge unnecessary data from the tables. Using stored procedures definitely provides the maximum flexibility in fixing the issues. I am going to check out Dapper based on your recommendation. Many thanks for outstanding work.

[@IAmTimCorey]

I am glad it was so helpful.

[@lokendrakumar16]

Hello Tim, Thank you for this great tutorial. This is one of the BEST tutorials on youtube on Entity Framework. Can you please share the Entity FrameworkCode First Approach tutorial, it would be very helpful for those who really like your tutorials and the way you explain. Thanks

[@IAmTimCorey]

I put that on my list, thanks.

[@Mo_TEK]

Thank you so much for your kind effort ❤️ Love from IRAQ .... and please let use know if some of EF problem in performance get better thanks again .

[@IAmTimCorey]

You are most welcome. As for the performance problems, mostly they are a result of not optimizing the C# code enough to make good database calls. I still prefer Dapper because it does not negatively impact performance on its own (your queries are either performant or they aren't but it is up to you).

[@adwaylele7626]

Great video, Tim. Really nice. I have got this thing going on with my team, where they want to keep using dapperish solution, while I advocate EF6. Regardless, I have shared the article with them. Overall, I like using ORMs for couple of reasons, not covered by you. 1. It's that, ORM forces streamlined access to db - discouraging tendency to write procedural code, saying fetchthis and processthat. 2. I also like it, when the business logic is centered in C#, and not spread over SQL and C#. Many times unsuspecting developers assume that query will fetch something as the name suggests, while SQL is a big patch of patch of unions spanning couple hundred lines. I actively discourage that kind of incremental stuff.

[@IAmTimCorey]

I agree with your overall premise, although I approach it differently. My mantra is "let SQL do what it does best and then let C# do the rest".

[@cjm3801]

Great information, Tim. Personal best practice is don’t use code first! Entity is great for help you quickly create class models and data access code but not for database creation. Thanks for all the great information as always!

[@IAmTimCorey]

Thanks for sharing!

[@kellenstuart4698]

That was really interesting to watch. Thank you for making this. I had no clue how to use that SQL profiler. I'm also curious if EF has a way to show the raw queries while you're on the breakpoint - would be nice to not have to setup those filters. I think I will still use EF because it does everything for you... I also think from a job standpoint that more people will expect you to know EF over Dapper. I definitely see your point though... I've seen developers just complain about the server hardware, when in reality, the code was terribly inefficient and nobody understands the ORM. Also, you should use VS code instead of notepad :p

[@IAmTimCorey]

I definitely recommend you fully understand EF before you use it in production. That comes from a LOT of practice, testing, and training.

[@kellenstuart4698]

@@IAmTimCorey I also appreciate that you know the technology you're criticizing. A lot of developers like to bash on technologies (like Entity Framework) yet they have never used it themselves enough to fully understand it - I see this a lot with Docker.

[@JuanManuelPalaciosPalacios]

This is an awesome video, i'm just learning about Entity Framework but starting from a database that is already created and on production, so this is different point of view. I didn't knew that i can create a DB from an entity class, as you said, great tools are available. Thanks for the tutorial, from now you have a new follower.

[@IAmTimCorey]

Glad it was helpful!